Bug 504810 - F11 libvirt managed machine stops at GRUB if virtio and IDE disk mix
F11 libvirt managed machine stops at GRUB if virtio and IDE disk mix
Status: CLOSED DUPLICATE of bug 507271
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Glauber Costa
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-09 11:11 EDT by erikj
Modified: 2009-06-22 08:43 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-22 08:43:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description erikj 2009-06-09 11:11:25 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
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

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 -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.
Comment 1 erikj 2009-06-09 11:12:42 EDT
Host pkg levels, meant to include this:

# rpm -q kernel qemu-kvm libvirt virt-manager
Comment 2 Glauber Costa 2009-06-10 11:36:04 EDT
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?
Comment 3 Mark McLoughlin 2009-06-19 06:27:02 EDT
Erik: could you attach the libvirt XML config for the guest that gives the original command line you posted?
Comment 4 Mark McLoughlin 2009-06-19 06:28:32 EDT
We only set boot=on for the first disk, so I suspect you just need to re-order to drivers in the guest XML?
Comment 5 erikj 2009-06-19 18:07:53 EDT
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.
Comment 6 Mark McLoughlin 2009-06-22 07:29:30 EDT
(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
Comment 7 Mark McLoughlin 2009-06-22 08:43:23 EDT
Okay, had simple a reproducer

*** This bug has been marked as a duplicate of bug 507271 ***

Note You need to log in before you can comment on or make changes to this bug.