Bug 837131 - RFE: provide way to reorder disks, and don't add new disks earlier in boot order than existing disks
RFE: provide way to reorder disks, and don't add new disks earlier in boot or...
Status: CLOSED DUPLICATE of bug 812134
Product: Virtualization Tools
Classification: Community
Component: virt-manager (Show other bugs)
unspecified
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Cole Robinson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-02 17:45 EDT by Robert Story
Modified: 2014-02-10 13:17 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-10 13:17:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Story 2012-07-02 17:45:45 EDT
Description of problem:
I created a new virtual disk for a VM (type IDE, pointing at raw device (lvm)). This disk became disk 0 (<address type='drive' controller='0' bus='0' unit='0'/>), which resulted in the VM not being able to boot.  Virt-manager has no way to change the controller/bus/unit to re-order drives.

Version-Release number of selected component (if applicable):
virt-manager-0.9.1-3.fc16.noarch

How reproducible:
every time

Steps to Reproduce:
1. create vm, install os, shut down vm
2. add second disk
3. start vm
  
Actual results:
no way to change controller/bus/unit number

Expected results:
a way to change order of devices

Additional info:
workaround: virsh edit machine-name, then manually edit info.
Comment 1 Cole Robinson 2012-10-01 19:48:37 EDT
Please provide virt-manager --debug when reproducing the issue (the attach which adds the wrong XML), and the final XML config which does not boot.
Comment 2 Cole Robinson 2012-10-21 15:18:51 EDT
Actually I understand what the issue is, if you have 2 disks, remove the first, add a new disk and it becomes the first disk + default boot target. 1) We shouldn't do that and 2) we need to provide a way to reorder disks.
Comment 3 Robert Story 2013-04-24 14:21:13 EDT
Nope, that's not it. I did not remove any disk, I simply used 'add hardware' to add a new disk. I just went to reproduce it, and I noticed that the default disk type (hda/ide) is different from the current disk type (vda/qcow2).

Here is the disk config from virsh dumpxml:

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/image/original.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/new.img'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

I'm guessing that maybe hda/ide devices get processed before vda/virtio devices, so the new disk is found first when booting. Indeed, I found that if I removed the  hda device and instead added a new virtio disk, I could still boot.

So maybe you can't force the boot search order to stay the same for different device types, but at the very least a warning that adding new disks (particularly of a different type) might change the order that drives are found and thus affect booting would be good.
Comment 4 Cole Robinson 2014-02-10 13:17:35 EST
This will basically be solved by using libvirt's fine grained boot ordering, which is tracked in another bug

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

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