Red Hat Bugzilla – Bug 504810
F11 libvirt managed machine stops at GRUB if virtio and IDE disk mix
Last modified: 2009-06-22 08:43:23 EDT
If you try to mix virtio and IDE emulated devices for a given virtual machine,
it could stop booting.
In my case, it would stop booting but would display 'GRUB' on the screen and
In the scenario I was trying, I just wanted to compare some tests on a device
imported to the guest using virtio and ide emulation. The root image is provided
to the guest via virtio.
When I tried to use virt-manager's storage management feature to delete the
2nd virtio disk and add it back in as IDE, the resulting machine wouldn't boot.
I was later able to make the virtual machine boot ok when I re-arranged the
qemu-kvm boot line some. The issue appears related to where the boot=on is
The libvirt-provided qemu-kvm command line looked like this:
/usr/bin/qemu-kvm -S -M pc -m 2048 -smp 8 -name f11-test -uuid 41ed0f4f-cb0d-7d6a-ffb6-b33106d519ef -monitor pty -pidfile /var/run/libvirt/qemu//f11-test.pid -boot c -drive file=/dev/sdb,if=ide,index=0,boot=on -drive file=/data/mirrors/redhat/fedora/releases/test/11-Preview/Fedora/x86_64/iso/Fedora-11-Preview-x86_64-DVD.iso,if=ide,media=cdrom,index=2 -drive file=/var/lib/libvirt/images/f11-test-1.img,if=virtio,index=0 -net nic,macaddr=54:52:00:4a:ee:0e,vlan=0,model=virtio -net tap,fd=20,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -soundhw es1370
I made some adjustments to the command line just to make it so I could start it
by hand. In addition...
I changed the index from zero to 1 for the IDE /dev/sdb disk. That didn't
help. Then I added boot=off for the /dev/sdb disk. That didn't help either.
Then I added "boot=on" to the virtio disk image and was able to bring the
system up fine.
Here is the command line I used that resulted in a machine working with respect
to the disk devices.
/usr/bin/qemu-kvm -M pc -m 2048 -smp 8 -name f11-test -uui41ed0f4f-cb0d-7d6a-ffb6-b33106d519ef -pidfile /var/run/libvirt/qemu//f11-test.pid -boot c -drive file=/dev/sdb,if=ide,index=1,boot=off -drive file=/data/mirrors/redhat/fedora/releases/test/11-Preview/Fedora/x86_64/iso/Fedora-11-Preview-x86_64-DVD.iso,if=ide,media=cdrom,index=2 -drive file=/var/lib/libvirt/images/f11-test-1.img,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:4a:ee:0e,vlan=0,model=virtio -net tap,fd=20,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -usbdevice tablet -soundhw es1370
The resulting system operated properly with respect to disks. The virtio root
disk booted ok, and I was able to access the IDE-emulated disk device (sdb on
the host, sda on the guest).
The resulting machine had broken networking, but I believe this is a function
of not making the proper networking adjustments to account for it not being
launched by libvirt.
I'm not sure how serious this issue is. Will many people be mixing virtio
and non-virtio? I'm not sure. I'm doing it from a testing perspective more
than a customer-centric perspective. So therefore, I won't be offended if it
is decided that this is lower priority.
Host pkg levels, meant to include this:
# rpm -q kernel qemu-kvm libvirt virt-manager
Every virtio disk that aims to be bootable has to include the boot=on flag.
Maybe danpb can say more about why it is not happening here?
Erik: could you attach the libvirt XML config for the guest that gives the original command line you posted?
We only set boot=on for the first disk, so I suspect you just need to re-order to drivers in the guest XML?
I'm keeping NODEINFO (today was all meetings... will try to get to this next
My point is just that I used the tools to manage the guest and it resulted,
in this situation, in a guest that wouldn't boot. I already know that
adjusting the qemu-kvm command line makes it work.
I'll do the test from comment #3 soon. thanks.
(In reply to comment #5)
> My point is just that I used the tools to manage the guest and it resulted,
> in this situation, in a guest that wouldn't boot.
Please give us a detailed set of steps to reproduce, then - somehow you ended up with a non-bootable disk as your first drive, which seems odd.
Oh, a virt-manager.log excerpt showing the steps taken would be useful too
Okay, had simple a reproducer
*** This bug has been marked as a duplicate of bug 507271 ***