[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-xen] FC6 initrd without xenblk?



On Wed, Apr 11, 2007 at 11:15:05PM +0800, Adrian Chadd wrote:
> On Wed, Apr 11, 2007, Paul Wouters wrote:
> 
> > > Is there a "better" way to do this for PVM under FC6? (this example is Debian etch
> > > DomU under FC6 Dom0.)
> > 
> > No :(
> > 
> > Because the dom0 didnt need the drivers, they're not put in the initrd for
> > the dom0, but it doesn't calculate in the fact we want to use the same initrd
> > for the guests. I'm probably sounding like a broken record asking for these
> > drivers in the default initrd for the xen kernel (which is used for both
> > dom0 and guests).
> 
> Thats really the case? I went looking for fc6 xen0 and xenU kernels like there
> was with FC5 but couldn't find it; I thought they'd then "do the right thing."

The separate  xen0 / xenU kernels were old style 'monolithic' Xen builds which
turned off loadable modules for a large class of drivers. This wasn't sustainable
long term where we're aiming to ultimately converge on a single kernel image.
ie, with upstream paravirt-ops we ultimately won't even need a special kernel-xen
for guest VMs - the regular 'kernel' will be able to auto-detect that it is running
on baremetal, vs Xen, vs VMWare.  Getting Dom0 to use paravirt-ops is a much harder
task, but it is still our long term goal - maintaining multiple kernels is just
not at all sustainable - as demonstrated by frequent periods where we have no
Xen update available to match baremetal :-(

So our long term goals of virtualization are to reduce & eliminate the 'special 
cases' for dealing with virtualization.

> Daniel, any chance of having at least xenblk in the fc6 initrd unless there's
> also a seperate initrd shipped, or split dom0/domU kernels like with FC5?

It is not going to happen. We provide a single kernel RPM, and the initrd is 
auto-generated based on the hardware profile of the OS in which the RPM is 
installed. Our recommendation is always to keep the DomU kernel inside the 
DomU OS image and manage it with the normal update tools. This gives a 
consistent management model across bare metal, Xen paravirt, Xen fullvirt,
VMWare, KVM, QEMU - each OS manages its own bits.

Even beyond just the xennet/blk modules, there are plenty of other non-hardware 
related kernel modules that a DomU may want to use - eg all the IPTables addons,
so regardless of xenblk/net you'll almost certainly need the kernel-xen RPM
installed inside the DomU regardless. With forthcoming generations of CPUs
it will be possible to securly hand-off hardware devices to DomUs too, still
further extends the set of kernel modules you want access to in DomU. Thus
it is impossible to pre-generate a initrd in Dom0 that will be suitable for
general use in DomU.

That all said - and as has been pointed out previously - if people still wish
to have kernel/initrd located in Dom0, and know exactly which specific set
of kernel modules their guest will use, they always the option of creating
another initrd-domU-2.6.19-XXX.img using the regular mkinitrd tools.


Regards,
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  -=| 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]