Description of problem: When IDE devices which defined and undefined addresses are provided to libvirt, the dev element (hda, hdd,..) is incorrectly generated and forces libvirt to assign duplicated addresses to these IDE devices. Version-Release number of selected component (if applicable): vdsm-4.16.32-1.el7ev How reproducible: 100% Steps to Reproduce: Create VM with two IDE disks (Disk01, Disk02) and start this VM. Stop this VM and create a new disk (aDisk01) (names are important as the engine passes the devices to vdsm alphabetically sorted) Start the VM Actual results: libvirterror: ecode: 1 edom: 10 level: 2 message: internal error: process exited while connecting to monitor: qemu-kvm: -drive file=/rhev/data-center/d0be66e7-f9e8-48b8-83a6-2fcd0a0fef7f/4ef9f093-4990-4de2-b3fd-92dd8e88c742/images/3f483bfb-34d4-4fb9-b3fb-c296b46739f5/8d0e717b-73f3-4f0c-a090-b7a4386a73c1,if=none,id=drive-ide0-0-1,format=raw,serial=3f483bfb-34d4-4fb9-b3fb-c296b46739f5,cache=none,werror=stop,rerror=stop,aio=native: Duplicate ID 'drive-ide0-0-1' for drive VMs with 2 IDE devices cannot be started after adding 3th disk if the disks name is earlier in the alphabet. Expected results: The VM start up and the Additional information: vdsm generated the following xml: Create VM with this definition: <disk device="disk" snapshot="no" type="block"> <address bus="0" controller="0" target="0" type="drive" unit="0"/> <source dev="/rhev/data-center/d0be66e7-f9e8-48b8-83a6-2fcd0a0fef7f/4ef9f093-4990-4de2-b3fd-92dd8e88c742/images/49290603-daf7-4c27-86d0-4ca48393067e/ebed8f33-53d3-4c53-a495-97418e178e34"/> <target bus="ide" dev="hda"/> <serial>49290603-daf7-4c27-86d0-4ca48393067e</serial> <boot order="1"/> <driver cache="none" error_policy="stop" io="native" name="qemu" type="raw"/> </disk> <disk device="disk" snapshot="no" type="block"> <source dev="/rhev/data-center/d0be66e7-f9e8-48b8-83a6-2fcd0a0fef7f/4ef9f093-4990-4de2-b3fd-92dd8e88c742/images/3557710c-7e87-4774-b950-f96af089c6a7/2e214081-9ca9-4f8b-9812-460904c82c87"/> <target bus="ide" dev="hdb"/> <serial>3557710c-7e87-4774-b950-f96af089c6a7</serial> <driver cache="none" error_policy="stop" io="native" name="qemu" type="raw"/> </disk> <disk device="disk" snapshot="no" type="block"> <address bus="0" controller="0" target="0" type="drive" unit="1"/> <source dev="/rhev/data-center/d0be66e7-f9e8-48b8-83a6-2fcd0a0fef7f/4ef9f093-4990-4de2-b3fd-92dd8e88c742/images/3f483bfb-34d4-4fb9-b3fb-c296b46739f5/8d0e717b-73f3-4f0c-a090-b7a4386a73c1"/> <target bus="ide" dev="hdd"/> <serial>3f483bfb-34d4-4fb9-b3fb-c296b46739f5</serial> <driver cache="none" error_policy="stop" io="native" name="qemu" type="raw"/> </disk> Keep in mind that The devices has the following addresses and dev names: hda - <address bus="0" controller="0" target="0" type="drive" unit="0"/> hdd - <address bus="0" controller="0" target="0" type="drive" unit="1"/> hdb - no address yet as it is a new disk The naming for IDE devices is strict. So 0-0-0-1 cannot be hdd, but must be hdb and not hdd. Engine does not pass the boot indexes so vdsm creates them on its own and then makes up the names based on the indexes. The problem is that the indexing is dome based on "First come first take" That is wrong as engine sends the devices randomly or rather alphabetically sorted based on the disk alias. The issue seems to be in Vm.normalizeDrivesIndices(..)
Tal, can you guys please take a look and share your thoughts? I suppose the order would need to change - or the vdsm side when assigning indices.
Seems similar to bug 1186817 which should cover the described issue as well (targeted for 4.0).
*** This bug has been marked as a duplicate of bug 1186817 ***