Bug 837131

Summary:	RFE: provide way to reorder disks, and don't add new disks earlier in boot order than existing disks
Product:	[Community] Virtualization Tools	Reporter:	Robert Story <rs>
Component:	virt-manager	Assignee:	Cole Robinson <crobinso>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, berrange, crobinso, dpierce, hbrock, jforbes, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-02-10 18:17:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Robert Story 2012-07-02 21:45:45 UTC

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 23:48:37 UTC

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 19:18:51 UTC

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 18:21:13 UTC

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 18:17:35 UTC

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 ***