Bug 1312936

Summary: libvirt assigns duplicate addresses for IDE devices
Product: Red Hat Enterprise Linux 7 Reporter: Roman Hodain <rhodain>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 7.2CC: jdenemar, rbalakri, rhodain, sapandit
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-01 14:47:15 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:

Description Roman Hodain 2016-02-29 15:00:24 UTC
Description of problem:
When devices which defined and undefined addresses are provided. Libvirt incorrectly assigns duplicate addresses to the devices and qemu fails.

Version-Release number of selected component (if applicable):
libvirt-daemon-1.2.17-13.el7

How reproducible:
100%

Steps to Reproduce:
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>

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


Expected results:
The first available address is assigned to the device.

Comment 2 Jiri Denemark 2016-02-29 15:30:31 UTC
This doesn't seem to be a libvirt bug. The XML contains three IDE disks (hda, hdb, and hdd) and it's mixing explicitly assigned address with no address. The problem is that device hdd is configured to be on ide0-0-1 which corresponds to hdb. Thus, when libvirt automatically adds an IDE address to hdb, it will conflict with the one assigned to hdd. Everything should work if the <address> element from hdd is removed, or if it is set correctly to ide0-1-1.

The most important question is what steps lead to such a wrong XML.

Comment 4 Jiri Denemark 2016-03-01 12:00:56 UTC
Is this about attaching an additional disk to a domain which already has two disks assigned? If so, could you please attach both the original domain XML (before trying to attach a new disk) and the XML generated after attaching the disk?

Comment 5 Roman Hodain 2016-03-01 13:57:36 UTC
(In reply to Jiri Denemark from comment #4)
> Is this about attaching an additional disk to a domain which already has two
> disks assigned? If so, could you please attach both the original domain XML
> (before trying to attach a new disk) and the XML generated after attaching
> the disk?

The reason is this:
http://www.ovirt.org/develop/release-management/features/ux/design/stabledeviceaddresses/

RHEV does not assign the addresses for the devices. When a VM with one disk is started the first time, it does not have any disk address assigned. The xml is passed without that and when the VM is up the RHEV manager asks for the addresses and stores them in its DB. When the VM is started next time the address is passed in order to keep the address persistent.

In the cease above the VM was originally started with two disk and cdrom (hdc I did not put it to the comment) and then the VM was stopped and a new disk was added. That is why there is one device without the address. RHEV assumes that libvirt will not create the devices with duplicate addresses. 

Based on your description I understand that libvirt assigns the addresses based on the dev element?

vdsm generates the dev element rather randomly. In his case I assume that it should be handled better in vdsm.

Comment 6 Jiri Denemark 2016-03-01 14:13:24 UTC
Yes, the relation between hd? and it's device address is quite strict on IDE bus. If no address is used, libvirt will assign it according to the target/@dev attribute so that the attribute matches what the guest OS will see. Mixing stored addresses with random dev attributes is not a very good idea especially when some of the disks have no address assigned yet.

Comment 7 Roman Hodain 2016-03-01 14:47:15 UTC
(In reply to Jiri Denemark from comment #6)
> Yes, the relation between hd? and it's device address is quite strict on IDE
> bus. If no address is used, libvirt will assign it according to the
> target/@dev attribute so that the attribute matches what the guest OS will
> see. Mixing stored addresses with random dev attributes is not a very good
> idea especially when some of the disks have no address assigned yet.

Closing as not a bug and opening new one on vdsm:

     https://bugzilla.redhat.com/show_bug.cgi?id=1313406