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 -- Fedora-xen mailing list Fedora-xen@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-xen
