[Fedora-xen] FC6 initrd without xenblk?

[Paul Wouters]

On Wed, 11 Apr 2007, Daniel P. Berrange wrote:

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

The OS can be detected as being a dom0 with the xen hypervisor underneath
it, and then include xenblk in the initrd creation for use by the guests.

> 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

In real life, people need to maintain old images like FC3/4/5, old Debian's,
Centos/RHEL and what not. Those cannot install kernel-xen images inside
them, so your "solution" does not work in real life.

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

This argument is wrong.

Most, if not all, of those device drivers can be obtained from the
guest's /lib/modules. It is only xenblk and raid and ext3 that we need
to read the other modules from the virtual disk. All the other hardware
drivers can be loaded later on, and do not require to be in the ramdisk.
So no, even if handing over other PCI devices or what not, I don't have
a problem with the driver not being in the initrd.

> 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

You are phrasing this rather wrong. I don't "wish it", I "require it" to
run old OS'es with xen-capable newer kernels.

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

And you are making us do this for *every* kernel you release, simply because
of the refusal to load a single driver. A driver that at most will be
unused, which if redhat wants, it could unload in rc.sysvinit, and which
takes up 22980 bytes of kernel memory on my xen server, which are all
loaded with 4GB of ram to provide memory to many guests to begin with.

All I want is per default to be able to read the virtual disk using xenblk
so i can load the rest of the drivers. You're being fundamentalist about
this issue.

Paul