RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1312936 - libvirt assigns duplicate addresses for IDE devices
Summary: libvirt assigns duplicate addresses for IDE devices
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-29 15:00 UTC by Roman Hodain
Modified: 2019-12-16 05:27 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-01 14:47:15 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2184781 0 None None None 2016-03-01 11:36:35 UTC

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
Note You need to log in before you can comment on or make changes to this bug.