anaconda needs a series of patches in order to support installing to kvm virtio guests. These patches pretty closely mirror how F-9 supports virtio, with the exception of the devMakeInode() patch isn't needed in F-9 since ananconda uses udev there. The nasty thing about this patch is that virtio_blk hasn't yet been assigned a major number, so we need to poke in /proc/devices for it. Note: these patches are untested at yet, so they're for illustration only atm.
Created attachment 328383 [details] Patch 1/7, Add virtio support to devMakeInode
Created attachment 328384 [details] Patch 2/7, Add virtio to module info
Created attachment 328385 [details] Patch 3/7, Explicitly include virtio_pci in the initrd
Created attachment 328386 [details] Patch 4/7, Probe on BUS_VIRTIO for devices
Created attachment 328387 [details] Patch 5/7, Sort virtio devices first
Created attachment 328388 [details] Patch 6/7, Add virtio max partition count
Created attachment 328389 [details] Patch 7/7, Probe BUS_VIRTIO again after probing BUS_PCI
OK, I've now tested this out, and it *mostly* works. There is a bug remaining, but I'm not sure if it is in my patches or if it is in anaconda itself. Basically, if I try to do an install to a guest where the hard drive is backed by a completely blank file (that is, all zeros), I get a traceback during pvcreate saying that the requested /dev device doesn't exist. This, in turn, seems to happen because after partitioning the device, the kernel isn't being told to refresh it's view of the partitions. That is, at the time of the error, /proc/partitions contains: 253 0 10485760 vda When it really should contain: 253 0 10485760 vda 253 1 102348 vda1 253 2 10383360 vda2 The thing is, the partition table is already on disk, as evidenced by fdisk -l /dev/vda: Disk /dev/vda: 10.7 GB, 10737418240 bytes 4 heads, 32 sectors/track, 163840 cylinders Units = cylinders of 128 * 512 = 65536 bytes Device Boot Start End Blocks Id System /dev/vda1 * 1 1600 102384 83 Linux /dev/vda2 1601 163840 10383360 8e Linux LVM So it just seems like the ioctl() to re-read the partition table isn't happening. Again, I'm not sure if that is a bug in my code (am I supposed to do that manually?), or if it something anaconda should be doing regardless. In any caes, working around this (by manually partitioning the device first) allows me to do a full install, so other than this issue these patches are ready to go. Chris Lalancette
(In reply to comment #8) <snip> > So it just seems like the ioctl() to re-read the partition table isn't > happening. Again, I'm not sure if that is a bug in my code (am I supposed to > do that manually?), or if it something anaconda should be doing regardless. In > any caes, working around this (by manually partitioning the device first) > allows me to do a full install, so other than this issue these patches are > ready to go. Thanks for the testing. About the issue you are seeing that is an issue with parted as is in RHEL-4. If you look at the parted sources and then at libparted/linux.c: 323 and further (the _device_probe_type() function), then you will see it sets the device type to PED_DEVICE_FILE for unknown devices like virtio disks, if you then look at linux_disk_commit() (line 1853 and further) you will see it will not do the ioctl if the type is PED_DEVICE_FILE. Fedora doesn't have this problem because the _device_probe_type() function sets the type to PED_DEVICE_UNKNOWN when it cannot find out what the type is, so it will still call the ioctl. > Chris Lalancette
Created attachment 328743 [details] Patch 1/6, Add virtio support to devMakeInode
Created attachment 328744 [details] Patch 2/6, Add virtio to module info
Created attachment 328745 [details] Patch 3/6, Explicitly include virtio_pci in the initrd
Created attachment 328746 [details] Patch 4/6, Sort virtio devices first
Created attachment 328747 [details] Patch 5/6, Add virtio max partition count
Created attachment 328748 [details] Patch 6/6, Probe BUS_VIRTIO again after probing BUS_PCI
OK, new patch series. As suggested by Hans, I dropped Patch 4/7 and made the probeVirtio unconditional in Patch 7/7. This makes it a little more clear, and makes this new series only have 6 patches instead of the previous 7. Also as suggested by Hans, the problem with not updating the kernel's partition tables was indeed a problem in parted. I created a patch for parted (BZ 479678), and with that in place, along with this new anaconda patch series, I was able to successfully install a RHEL-4 guest on a series of virtio disks (even blank ones). Chris Lalancette
Thanks, All patches committed now, changing status to modified.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Install with: # qemu-kvm -drive file=/root/kvm.img,if=virtio,boot=on -net nic,model=virtio,macaddr=00:16:41:E4:1D:FF,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0,ifname=vnet0 -m 512 -cdrom /root/boot.iso -boot d Default partitioning, default package set - PASS. lsmod | grep virtio in rescue mode shows: virtio_blk 8137 3 - Live 0xe081f000 virtio_net 10945 0 - Live 0xe08a9000 virtio_pci 8385 0 - Live 0xe08a5000 virtio 5445 3 virtio_blk,virtio_net,virtio_pci, Live 0xe0866000 virtio_ring 4033 1 virtio_pci, Live 0xe0864000 The system was not able to boot but I believe this is due to bug in mkinitrd. See bug 479239 for the mkinitrd part. I'm moving this to VERIFIED.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0978.html