Bug 507271

Summary: libvirt always places IDE disks before virtio/scsi disks
Product: [Fedora] Fedora Reporter: IBM Bug Proxy <bugproxy>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 11CC: berrange, clalance, crobinso, ehabkost, erikj, gcosta, gczarcinski, itamar, jforbes, markmc, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 521053 (view as bug list) Environment:
Last Closed: 2009-11-10 03:28:48 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 480594    
Attachments:
Description Flags
Screenshot showing guest unable boot after adding IDE disk
none
Screenshot showing IDE disk creation parameters none

Description IBM Bug Proxy 2009-06-22 00:50:31 EDT
=Comment: #0=================================================
PAVAN NAREGUNDI <pavan.naregundi@in.ibm.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@in.ibm.com> - 

Screenshot showing IDE disk creation parameters


=Comment: #3=================================================
MOHAN K. MOHAN RAJ <mohan@in.ibm.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.
Comment 1 IBM Bug Proxy 2009-06-22 00:50:40 EDT
Created attachment 348849 [details]
Screenshot showing guest unable boot after adding IDE disk
Comment 2 IBM Bug Proxy 2009-06-22 00:50:48 EDT
Created attachment 348850 [details]
Screenshot showing IDE disk creation parameters
Comment 3 Mark McLoughlin 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);
    ...
}
Comment 4 Mark McLoughlin 2009-06-22 08:43:23 EDT
*** Bug 504810 has been marked as a duplicate of this bug. ***
Comment 5 Daniel Veillard 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
Comment 6 Daniel Berrange 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.
Comment 7 IBM Bug Proxy 2009-06-29 03:50:58 EDT
------- Comment From mohan@in.ibm.com 2009-06-29 03:41 EDT-------
Redhat,

Any update?
Comment 8 Daniel Veillard 2009-07-02 10:28:26 EDT
In response to #7, based on #5 and #6 there is a couple of approaches which could
be tried to get rid of this behaviour, but that has to be discussed and done
upstream, i.e. on the libvir-list@redhat.com see:
   https://www.redhat.com/mailman/listinfo/libvir-list

because this has the potential of breaking existing setups. Once the discussion
has been done upstream, getting a bug fix should not be the hardest part.

Daniel
Comment 9 Mark McLoughlin 2009-09-03 07:10:57 EDT
Upstream commit to fix this:

  http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=2d6adabd53
Comment 10 IBM Bug Proxy 2009-09-07 06:20:47 EDT
------- Comment From santwana.samantray@in.ibm.com 2009-09-07 06:12 EDT-------
Hi,

I was able to reproduce this bug in Fedora12 Alpha release(k.v- 2.6.31-0.125.4.2.rc5.git2.fc12.x86_64). The guest isn't booting up after adding a IDE virtual storage.

Thanks,
Santwana

------- Comment From pavan.naregundi@in.ibm.com 2009-09-07 06:14 EDT-------
(In reply to comment #11)
> Upstream commit to fix this:
>
> http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=2d6adabd53
>

Redhat, Is this fix is in current F12 rawhide?
Comment 11 Justin M. Forbes 2009-10-07 13:08:52 EDT
While I don't believe it was in rawhide a when you tested, it is certainly in rawhide now.  Do you mind testing with current F-12 rawhide?
Comment 12 IBM Bug Proxy 2009-11-04 07:12:08 EST
------- Comment From santwana.samantray@in.ibm.com 2009-11-04 07:02 EDT-------
Hi

I verified this issue in the latest F12 rawhide release(k.v-2.6.31.5-96.fc12.x86_64), and the issue seems to be fixed.The guest was able to boot by adding IDE virtual storage. We can close this issue.

Thanks,
Santwana
Comment 13 Mark McLoughlin 2009-11-10 03:28:48 EST
(In reply to comment #12)
> We can close this issue.

Thanks for testing.

The bug is filed against Fedora 11, but since Santwana is the only one to have reported the problem, I'm fine with just closing it now that it's fixed in rawhide.