Re: [Xen-users] XenU installs

[Tim Post <tim.post@xxxxxxxxxxx>]

On Tue, 2007-06-05 at 21:47 +0100, Mark Williamson wrote:
> Hi Tim,
> 
> I'll leave discussion of your ideas for other mails, but I just wanted to 
> clarify what I was thinking of:
> 
> > As for strapping guests "ready to rock with LAMP" , debootstrap does the
> > best job on the most different platforms in my experience. rpmstrap is
> > broken (or was last I checked) because nobody has updated the rpm list
> > since centos 3 / fc *2* I believe?
> >
> > If you really want to be able to configure any os from any os for a
> > paravirt guest, you need some kind of meta package ' Rosetta stone '. I
> > can't say that one doesn't exist, but I've yet to find one that includes
> > all popular distros.
> 
> 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.

Just something consistent and natural-language like on dom-0 is what I
was thinking of, looks like we're on the same page. I guess we could
call them "Xen" meta packages, and they'd still be useful to people
using just the stuff native in 2.6. I guess it would work well for
anyone using a technology that got a little help from QEMU.

> 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.

> To me the obvious way to accomplish this would be to have some sort 
> of "xen-metainfo.xml" file that compliant install CDs feature at a well-known 
> path such as "xen/xen-metainfo.xml".  This file would specify the location of 
> a Xenified kernel, and an initrd that can load the installer proper.  This 
> would support the mode of installation current RH guests support - if you can 
> *find* the Xen install kernel and initrd, then anaconda will appear for you 
> and make the install friendly.
> 
> More generally, such a metadata file could also specify:
> * boot time options that need to be passed to the kernel
> <bootargs>
>       <arg>install</arg>
>       <arg>initrd</arg>
> </bootargs>
> 
> * user configurable boot time options
> <user-bootargs>
>       <arg values="framebuffer|vnc|text|auto">installmode</arg>
>       <arg>installserver</arg>
> </user-bootargs>
> 
> * different kernel "modes" available (e.g. are kernels available for install 
> on x86_32, x86_32p, x86_64) so that Xen can start the right one in order to 
> kick off the install
> <kernels>
>       <kernel>
>               <name>Linux 2.6.18 32-bit/PAE domU</name>
>               <path>path/to/image</path>
>               <capable>x86_32p</capable>
>               <capable>SMP</capable>
>       </kernel>
> </kernels>
> 
> * how the distro expects devices to be setup (e.g. does this install require 
> a 
> network device, can it do DHCP?)
> <devices>
>       <required>
>               ...
>       </required>
>       <supported>
>               ...
>       </supported>
> </devices>
> 

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.

This is what was steering me to a sqlite backed non blocking service to
run on dom-0 that spit out config values in various formats from xml
templates. I was thinking deposit the configs in a future/ directory on
the vbd image prior to strapping it, and have the default init.d run a
post install that removes itself. 

> This same information could be leveraged by the Xen Enterprise tools, 
> virt-manager, Yast, etc.  In general, perhaps it would be possible to have 
> a "virt-info.xml" that contains details of lguest support, KVM paravirtual 
> support etc.
> 
> I wonder if there would be any distributor interest in something like 
> this...?  
> If so, I'd be happy to put together a more detailed proposal we could argue 
> about on xen-devel.

Many many many many many. 

Look at www.3tera.com which is based on xen 2.0.7 (at last I checked).

For a free version of AppLogic to exist, this would be the first step
and time VERY well spent. Its got so many uses beyond just what we'd use
it for if modified ever so slightly, It really makes a packagers job
easier.

Appliances become easier to make, you could make load balancers, storage
servers, firewalls of various types, a vyatta or quagga router, whatever
you wanted. There could be a ready made meta template for it you could
download like a torrent.

You also make UI creation so much easier. Now its a simple question of
turning text descriptors into args that only one thing has to deal with.

What your making is more or less a packagers swiss army knife. 

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*.

> 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