I had to roll a custom initrd for 2.6.19-1.2911.6.5.fc6xen which included xenblk during boot: [root@hosting-3 ~]# mkinitrd -f --preload=xenblk --with=xenblk /boot/initrd-2.6.19-1.2911.6.5.fc6xen.img.1 2.6.19-1.2911.6.5.fc6xen The default initrd didn''t load xenblk and thus domU didn''t have any block devices, halting the boot process right in its tracks. Is there a "better" way to do this for PVM under FC6? (this example is Debian etch DomU under FC6 Dom0.) My config file: [root@hosting-3 ~]# cat /etc/xen/servers/test1 kernel = "/boot/vmlinuz-2.6.19-1.2911.6.5.fc6xen" ramdisk = "/boot/initrd-2.6.19-1.2911.6.5.fc6xen.img.1" memory = 128 name = "test1" vif = [ ''bridge=xenbr0.4'' ] disk = [ ''phy:Hosting3/XEN_test1_root,sda1,w'', ''phy:Hosting3/XEN_test1_swap,sda2,w'' ] root = "/dev/sda1 ro" on_crash = "preserve" Thanks, Adrian
On Wed, 11 Apr 2007, Adrian Chadd wrote:> I had to roll a custom initrd for 2.6.19-1.2911.6.5.fc6xen which included > xenblk during boot: > > [root@hosting-3 ~]# mkinitrd -f --preload=xenblk --with=xenblk /boot/initrd-2.6.19-1.2911.6.5.fc6xen.img.1 2.6.19-1.2911.6.5.fc6xen > > The default initrd didn''t load xenblk and thus domU didn''t have any block devices, > halting the boot process right in its tracks. > > 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). Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
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." 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? 2c, Adrian
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 -=|
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 aIn 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 setYou 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