Bug 521053 - libvirt always places IDE disks before virtio/scsi disks
Summary: libvirt always places IDE disks before virtio/scsi disks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt
Version: 5.5
Hardware: x86_64
OS: All
medium
medium
Target Milestone: rc
: ---
Assignee: Daniel Veillard
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-03 11:15 UTC by Mark McLoughlin
Modified: 2010-08-03 15:28 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 507271
Environment:
Last Closed: 2010-03-30 08:09:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
backport of the upstream patch to RHEL-5 (9.20 KB, application/octet-stream)
2009-11-18 16:40 UTC, Daniel Veillard
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0205 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2010-03-29 12:27:37 UTC

Description Mark McLoughlin 2009-09-03 11:15:38 UTC
+++ This bug was initially created as a clone of Bug #507271 +++

=Comment: #0=================================================
PAVAN NAREGUNDI <pavan.naregundi.com> - 

Screenshot showing guest unable boot after adding IDE disk

Fedora11 guest could not boot by adding additional IDE virtual storage.

Host: Fedora11
Guest: Fedora11

Steps:
1. F11 guest is installed with SCSI disk emulation using virt-install.
2. Shutdown the installed guest and add the additional IDE virtual storage.
        Steps to add additional IDE storage
        a. open the F11 guest in virt-manger
        b. Go to Details -> Add Hardware -> Storage(Hardware Type)
        c. Select File(disk image) and go to Browse and create a image of any type.
        d. Select device type as "IDE disk"
        e. Then Forward -> Finish
        Now  additional IDE disk have been added. 
3. Now if the guest is started, it could not boot giving the error shown in attached screeshot

virt-manager-0.7.0-4.fc11.x86_64
python-virtinst-0.400.3-8.fc11.noarch
libvirt-0.6.2-8.fc11.x86_64
qemu-system-x86-0.10.4-4.fc11.x86_64
=Comment: #1=================================================
PAVAN NAREGUNDI <pavan.naregundi.com> - 

Screenshot showing IDE disk creation parameters


=Comment: #3=================================================
MOHAN K. MOHAN RAJ <mohan.com> - 
After adding additional drive when we start the image, it tries to boot from the newly added drive.
Here is the kvm command line:

/usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name f11 -uuid ce5436fc-b242-d265-d5fc-20921a6dfd40
-monitor pty -pidfile /var/run/libvirt/qemu//f11.pid -boot c -drive
file=/root/test,if=ide,index=0,boot=on -drive file=/root/f11.qcow2,if=scsi,index=0 -net
nic,macaddr=54:52:00:06:69:ba,vlan=0,model=virtio -net tap,fd=17,script=,vlan=0,ifname=vnet0 -serial
pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0


I manually changed the kvm parameters to:
/usr/bin/qemu-kvm -M pc -m 512 -smp 1 -name f11 -uuid ce5436fc-b242-d265-d5fc-20921a6dfd40 -monitor
pty -boot c -drive file=/root/test,if=ide,index=0 -drive
file=/root/f11.qcow2,if=scsi,index=0,boot=on -net nic,macaddr=54:52:00:06:69:ba,vlan=0,model=virtio
-net tap,fd=17,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -usbdevice tablet

Now we could boot the kvm image.

--- Additional comment from bugproxy.com on 2009-06-22 00:50:40 EDT ---

Created an attachment (id=348849)
Screenshot showing guest unable boot after adding IDE disk

--- Additional comment from bugproxy.com on 2009-06-22 00:50:48 EDT ---

Created an attachment (id=348850)
Screenshot showing IDE disk creation parameters

--- Additional comment from markmc on 2009-06-22 08:40:38 EDT ---

Okay, problem is simple - take a guest with a virtio root device, add an IDE disk and qemu-kvm gets launched with with:

  qemu-kvm ... -drive file=...,if=ide,boot=on -drive file=...,if=virtio

rather than:

  qemu-kvm ... -drive file=...,if=virtio,boot=on -drive file=...,if=ide

Problem is how we sort disk devices:

int virDomainDiskCompare(virDomainDiskDefPtr a,
                         virDomainDiskDefPtr b) {
    if (a->bus == b->bus)
        return virDiskNameToIndex(a->dst) - virDiskNameToIndex(b->dst);
    else
        return a->bus - b->bus;
}

static virDomainDefPtr virDomainDefParseXML(virConnectPtr conn,
                                            virCapsPtr caps,
                                            xmlXPathContextPtr ctxt, int flags)
{
    ...
    qsort(def->disks, def->ndisks, sizeof(*def->disks),
          virDomainDiskQSort);
    ...
}

--- Additional comment from markmc on 2009-06-22 08:43:23 EDT ---

*** Bug 504810 has been marked as a duplicate of this bug. ***

--- Additional comment from veillard on 2009-06-22 08:52:48 EDT ---

I don't see how the problem could be avoided without tagging the boot
device in the XML definition. That should be looked at upstream (i.e.
on the mailing-list) because this has the potential to break a lot
of setup if not done right.

Daniel

--- Additional comment from berrange on 2009-06-22 09:00:30 EDT ---

I'm at a loss to explain *why* we sort disk devices in the first place, as opposed to always keeping them in parse order. No other device types are ever sorted. I'd be half-inclined to just remove the sorting, but will need to check the CVS history to see if there were any enlightening comments at the time sorting was originally added. I have a feeling it might be a hang over from XenD which has a tendancy to return devices in a randomized order each time - if that turns out to be true the sorting should just be done in the Xen driver not the generic parser code.

Independently of this though, it may well still be beneficial to track the bootable flag against specific disks.

--- Additional comment from markmc on 2009-09-03 07:10:57 EDT ---

Upstream commit to fix this:

  http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=2d6adabd53

Comment 1 Daniel Veillard 2009-11-18 16:40:39 UTC
Created attachment 370132 [details]
backport of the upstream patch to RHEL-5

Comment 2 Daniel Veillard 2009-11-25 16:10:05 UTC
libvirt-0.6.3-22.el5 has been built in dist-5E-qu-candidate with
the fixes,

Daniel

Comment 4 Gunannan Ren 2009-12-30 11:59:09 UTC
The bugs has been fixed in libvirt-0.6.3-28.el5.

On RHEL5u4 released system with libvirt-0.6.3-20.el5, after adding an additional IDE disk, boot the virtual machine installed with virtio disk emulation , the kvm command line is as follows:

/usr/libexec/qemu-kvm -S -M pc -m 1024 -smp 1 -name rhel5u4kvm -uuid 40e53f4c-5b66-fa11-4ed2-fdca1f92250a -monitor pty -pidfile /var/run/libvirt/qemu//rhel5u4kvm.pid -boot c -drive file=/var/lib/libvirt/images/moredisk.img,if=ide,index=0,boot=on -drive file=,if=ide,media=cdrom,index=2 -drive file=/var/lib/libvirt/images/rhel5u4kvm.img,if=virtio,index=0 -net none -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-us

and with libvirt-0.6.3-28.el5
the kvm command line is:

/usr/libexec/qemu-kvm -S -M pc -m 1024 -smp 1 -name rhel5u4kvm -uuid 40e53f4c-5b66-fa11-4ed2-fdca1f92250a -no-kvm-pit-reinjection -monitor pty -pidfile /var/run/libvirt/qemu//rhel5u4kvm.pid -boot c -drive file=/var/lib/libvirt/images/rhel5u4kvm.img,if=virtio,index=0,boot=on -drive file=,if=ide,media=cdrom,index=2 -drive file=/var/lib/libvirt/images/moredisk.img,if=ide,index=0 -net none -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-us

Comment 9 errata-xmlrpc 2010-03-30 08:09:54 UTC
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-2010-0205.html


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