[et-mgmt-tools] VM images

[David Lutterkort]

On Mon, 2007-06-11 at 13:46 +0100, Daniel P. Berrange wrote:
> On Fri, Jun 08, 2007 at 11:22:10PM +0000, David Lutterkort wrote:
> > * The metadata format allows specifying alternative ways of booting the VM,
> >   depending on the host platform. The code tries to find a matching boot
> >   descriptor using libvirt's capabilities; that matching code probably
> >   needs some love
> 
> I'm finding this matchup between guest type and files a little wierd and
> wondering how well it will work in practice. In the example there you are
> basically distributing a single root filesystem, and then separate /boot
> filesystems which are then matched up depending on whether todo HVM vs
> paravirt. 

Look at it from the user's point of view: Are you interested in a 'app
foo appliance' or in a 'app foo for paravirt Xen w/ PAE support'
appliance ? If you want to keep users from appreciating the finer points
of this, you'll need to capture it in metadata. And you'll either make
the distinction what you run when you download (one image per host
'type') or when you are about to run the image (one image for all host
types) Should users really d/l a few 100 MB of stuff to discover that
they should have clicked on the 'Xen pv w/ PAE' link rather than the
'Xen pv w/o PAE' link ?

> A couple of points
> 
>  1. Yuk

It's definitely a bit kludgey, but than any other way of achieving the
same thing is even worse. On the upside this is something that's not
appliance specific, i.e. you can create base images that do the yucky
stuff regardless of the actual application your appliance runs.

And it seems a tad less yucky than having the appliance boot hvm, ask an
XML-RPC server if pv is ok, and then booting pv.

>  2. Linux specific ? Does Solaris have a concept of /boot which can be
>     easily separated out for HVM vs Paravirt booting ? 

I don't know; but it does have a concept of mountpoints and symlinks, so
you could fake this /boot business.

> Is this even possible under Linux in the general case ?

The first thing you run into when you have this setup is that inittab
has an entry for xvc0 for pv, but that that entry gets in the way for
fv. You can get around that by symlinking/bindmounting /etc/inittab into
the /boot disk (which should probably not be called /boot disk anymore)

>  eg different Xorg configs - Cirrus vs fbdev, 

No idea; though I think not having to maintain n root images for n host
types would be pretty attractive.

> different filesystem names in /etc/fstab ? 

Mount-by-label or symlink/bindmount

> Different kernel modules listed in /etc/sysconfig/
>  3. Yuk !
>  4. How do you generate the filesystems? If I'm using the Fedora live CD
>     creation tools to do a chroot based install and image generation, I
>     can choose to install kernel, or kernel-xen, or both. So I'll end up
>     with a /boot containing a HVM suitable kernel, or a paravirt kernel.

I used a full virt-install.

>     Most image generation tools won't even generate a separate image file
>     for /boot, just having one main rootfs.

We'd need that ability anyway, e.g. to separate system from data disks
for image-based updates.

> I can see we have a use case for the image description format to be able to
> describe a image requiring HVM or PV, but is there really a compelling case
> for a single distributed image to be able todo both ? Seems like adding a
> lot of complexity for not all that much gain.

Users will have to understand a lot less about virtualization with this
than they'd have to without it. And they can change their mind about
which host they want to deploy on w/o having to download a whole new
image.

> Particuarly if we look forward
> to 12 months hence when Xen paravirt opts is merged upstream LKML and there
> is only a single kernel image capable of doing both.

Will that address PAE ? What about the other HW differences you
mentioned above, like Xorg ? 

>  Looking at the other
> view, there is going to be increased use of paravirt drivers within HVM 
> guests, further reducing the use cases for separate paravirt kernels.

And an even bigger need to express that cleanly (it's not like PV
kernels are on the brink of extinction) - if the tool doesn't support
expressing whether/what kind of PV drivers are needed, that complexity
has to live in user's heads. The download pages for appliances (e.g.
[1]) already make my head spin.

> IMHO we'd be better off just saying there's a single filesystem image,and
> removing the funky mapping between FS & boot types. Then <boot> element
> would then merely describe what this filesystem is capable of booting, beit
> HVM, or paravirt or both (once paravirt_ops Xen is available). 

One thing the metadata doesn't express well is the scenario of a unified
pv/fv kernel.

> If people really want the ability to provide images in short term which do 
> both HVM and paravirt, then effort is better focused on making it easy for
> the image creation tools to spit out two separate sets of image.

Will unified kernels really do away with all the differences between hv
and pv from the guest's POV ?

David

[1] http://www.rpath.org/rbuilder/project/lochdns/