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. A couple of points
1. Yuk
2. Linux specific ? Does Solaris have a concept of /boot which can be
easily separated out for HVM vs Paravirt booting ? Is this even possible
under Linux in the general case ? eg different Xorg configs - Cirrus
vs fbdev, different filesystem names in /etc/fstab ? 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.
Most image generation tools won't even generate a separate image file
for /boot, just having one main rootfs.
5. Yuk ;-)
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. 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. 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.
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).
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.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
