Re: [Xen-users] XenU installs

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> > Well, the Rosetta Stone package is exactly the kind of thing I'd like to
> > eliminate here.  Obviously for legacy guests that are already out there
> > it might be nice to have something like this.  However, it doesn't seem
> > scalable for the dom0 system to always understand what we're installing
> > in guests.
>
> Ah I think we're talking about the same thing, I say Rosetta more in the
> historical context and not alluding to the actual work going on trying
> to make a map of distro packages. I don't have links to them handy but I
> found 3 different people trying to do this independently of each other.
> None of them getting very far.

Hmmm, OK.  I guess I was thinking of the "Rosetta stone" approach as being 
some kind of central store of knowledge regarding how all the different 
distros express things.  AFAIK this is how, for instance, virt-install 
handles things: it contains knowledge about how to kick off installations of 
FC, RHEL, and other distros.

A number of distros now have installers (e.g. RHEL, Fedora, SLES) which can 
trivially run *within* a Xen domain so long as you know *how* to start them.  
It seems relatively unfortunate for each and every Xen management tool to 
need to understand these layouts.

For instance, XenEnteprise might contain one implementation of "how to 
install" for each of these distros.  virt-manager another...  Other people 
might install them by just memorising the necessary paths and putting this 
stuff into a Xen config file.

What IMO we *ought* to have is a simple way of describing how _to start_ an 
install of a paravirtualised Xen-aware guest.  To begin with, that'd be all 
we want and I think it would be a big win in itself.

Generalising slightly, I guess I'm not really proposing initially a way to 
simplify installs.  I'm proposing a vendor-neutral way to make an ISO 
the "bootable" for a paravirtualised system.

For "legacy" OSes, we'd need a database of meta-info files describing how to 
kick off a paravirt install of NetBSD, RHEL, Fedora, SLES, etc.  Distributors 
could include a meta-info file on their future ISO releases so that they'd be 
self-describing and not require users to update their meta-info database.

> > A nice simple way to get this working would be for everyone to supply a
> > grub.conf that pygrub can grok, then folks can just choose the "install
> > Xen" option from the menu.  However, not everybody uses grub, and
> > possibly it doesn't suit their needs.  Lets take the idea of a CD-ROM
> > config file a bit further, then...
> >
> > I guess what I'm proposing is _logically_ a "package format" for
> > encapsulating an OS distribution installer.  A kind of "Xen package
> > format".  This doesn't have to literally involve a new kind of package,
> > but the kind of simplicity I'd be looking for is: any distro that has a
> > Xenified kernel can support the XenInstall Spec and will easy to install,
> > in a uniform way on any Xen host.
>
> Ok, but how to have it install the services you want at the same time?
> Could packages like 'php5-lighttpd-fastcgi' make a home in these meta
> structures too so guests could come 'turn key' after being installed?
>
> I would love to be able to strap a Centos5 guest with everything I
> wanted out of yum, and have it follow some scripts or macros I wrote to
> install a few things from source.

Can't you do that sort of thing using RedHat's kickstart?

I actually think this kind of thing is kinda orthogonal to my proposal, 
because it's not really specific to Xen guests...  You'd really want to be 
able to specify this for any install, whether native or virtualised, mmm?

> Perhaps add ...
>
>       <post-installed>
>               <yum>perl make gcc mysql-server ... ... </yum>
>               <hg>xenbits.xensource.com/example.hg</hg>
>               <deb> ... ... </deb>
>               <emerge> ... ... </emerge>
>               <sh> ... ... ... </sh>
>       </post-installed>
>
>       <misc>
>               <root>shadowed:blahblah</root>
>       </misc>
>
> I don't want to turn your XML file into a Makefile ... though there are
> cases where you'd need bools in the xml file
>
>       <action type=OR_TRUE,OR_FALSE,OR_EXIT_FAILURE,OR_EXIT_SUCCESS>
>
> AND isn't really needed, its made by lack of OR. We'd need some sanity
> checking because that's a lot of stuff going on unattended if 'auto' is
> the mode.
>
> I've been using a simple bash script that reads a pipe delimited file
> like this :
>
> [vif] backing=br0|mac=xxx|vifname=xxx
> [vbd] type=lvm|backing=/dev/blah|name=sda1|type=ext3|size=10G|
> mount=/home
>
> XML would be much better, bash is really ugly but the syntax is pretty
> much the same.
>
> My utility would then 'grind' that down and give lvm some instructions,
> copy the template, write the etc/ files, and then call yum or aptitude
> to do some stuff.
>
> > A config file like this would facilitate an install process more like:
> >
> > ---
> > # xm guest-install ~/debian-install.iso
> > Looking for Xen/x86_32p kernel... found
> > Select installation mode "[framebuffer/vnc/text/auto]": _
> > Starting guest operating system...
> > ---
> >
> > This way nobody has to have a detailed understanding of how other
> > distributions structure their install CDs.  The key point is that the CDs
> > would be *self describing*.  Everyone can still use their own preferred
> > installation methods, so long as they supply enough information to tell
> > Xen how to get started.
>
> Exactly what I want. I hope to go a little more in depth with it and
> help them use the distro packaging mechanism so the VM comes out the
> door ready to meet requests.
>
> I tossed this out a few months ago, one of the things people replied
> with the most is a desire to easily edit guest configs without the fuss
> of having to login to the guest.

Mmmmmm.  Agreed on basically all counts.  Also I think that this is still the 
kind of thing you'd want to be able to leverage natively too so I think it 
comes outside the scope of what I'm looking at...

> Please do post a blueprint, could I possibly suggest xen-tools since
> xen-devel is about to really pick up in traffic?
>
> The neat part about this project is everyone can work on it, not just
> kernel and hypervisor hackers. Lots of people make Xen tools just so
> they can contribute *something*.

I'm hoping I'll be able to take a look at the base problem of making install 
CDs "just work" for Xen guests.  This could potentially involve some 
enhancements to pygrub, but I think there may be better ways of getting the 
Just-Workness in there.

Perhaps a wider discussion needs to be had with vendors about automating 
deployment in VMs: the same things that you need with mass deployments on 
physical machines become even more important when you've gone virtual.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users