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 stay there. 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 provided. 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 kernel-2.6.29.1-102.fc11.x86_64 kernel-2.6.29.4-167.fc11.x86_64 qemu-kvm-0.10.4-4.fc11.x86_64 libvirt-0.6.2-11.fc11.x86_64 virt-manager-0.7.0-5.fc11.x86_64
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 week). 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 ***