NB, to avoid potential confusion, my suggestion in that mail thread above is for *libvirt* to assign device aliases at XML define time, *not* to allow applications to set the device aliases. If we did the latter, then apps would need to understand QEMU's rules for valid device aliases, and I don't think that's desirable.

Relying on libvirt to create an alias to assign eliminates a couple of problems (adherence to naming rules, and clashing names, for starters), but it is problematic because the device won't have a name until after it has been added, so the only way to determine which device is the one you've just added is to compare the dumpxml from before and after the addition.

How restrictive are qemu's rules? I think it allows alphanumeric and ".".

Using '.' is risky; sticking to valid C99 identifiers is the safest bet, if you also avoid leading or doubled underscores.

Is there any way to extend libvirt API for hotplug (or add a new one) that returns the canonical XML snippet of the device just added, to make it easier to see which alias got assigned during the addition without having to parse the entire pre- and post-addition domain XML?

NB, we also use the ID alias of hardware devices as a base name to use for ID alias of the corresponding backend. In addition, if we allowed user specified IDs, then we' have to take care that any auto-generated names we create don't clash with user specified names.

Another solution would be the decoupling of the qemu device-name and the mgmt device-name. Possible names for such a tag or attribute could be "name", "ref", "id".

It could look like this:

    <video>
        <name>myvideodevice</name>
        <alias name='video0'/>
    </video>

or like this:

    <video name="mydevice">
        <alias name='video0'/>
    </video>

I think decoupling naming on administration level from qemu level, simplifies this RFE. Libvirt could at the beginning completely ignore the name attribute.

Future possible enhancements would be:

 - Libvirt could check for name collisions
 - Libvirt might auto-fill such a name based on the alias, an uuid, ... (but might lead back to where we are right now with the alias)
 - Libvirt could provide an api to fetch the device via this name
 - Libvirt could allow detaching devices via that name

Also, the charset for the name does not depend on qemu, which allows another very common solution to avoid conflicts: Namespacing the name. E.g. 'name="libvirt.org/qemualias' for auto-generated names. I know, not very XMLish, but a very simple and effective solution.

(In reply to Daniel Berrange from comment #5)
> NB, we also use the ID alias of hardware devices as a base name to use for
> ID alias of the corresponding backend. In addition, if we allowed user
> specified IDs, then we' have to take care that any auto-generated names we
> create don't clash with user specified names.

you can put it the other way around, making it the responsibility of user to not create any clash. I think even with the constraints on characters it can be as simple as a prefix, e.g. "ovirt-video0". Libvirt's own devices won't have the same prefix. And just bail out on any clash. 
Now oVirt can easily identify it's so-called managed devices and those it shouldn't touch, and it can reliably identify its devices in the resulting XML.
That's the core problem. The management layer is not the one generating the final XML as it can be altered by vdsm hooks, making the matching problematic

How about combining comment 8 and comment 6? Lets have:

<video>
  ...
  <alias name='video0' user='ovirt-myAwesomeVideo'/>
</video>

the @name attrib would be produced by libvirt at the time it's starting the domain, @user would be supplied by user, parsed at define time and otherwise untouched by libvirt (i.e. when talking to qemu we would still use libvirt generated ones). Then we could allow this user supplied alias to appear wherever we allow libvirt generated one, e.g.:

virsh update-device $dom

It would be user responsibility to not provide clashing strings as those aliases generated by libvirt would have higher priority. That way this should be fairly easy to implement as we don't have to disrupt alias generating system we already have.

I really don't like the idea of adding an arbitrary extra application specific name in here that doesn't map to anything in the hypervisor and is just arbitrarily different from the existing name we already have. 

We could consider allowing a UUID to be recorded per device though - that has benefits over using a name, given its well-defined format and particularly its fixed size. IIRC, some hypervisor platforms do have a UUID associated with devices that could potentially be mapped in

The other thing we can easily do is switching from auto-assigning aliases at start time, to assigning them at define time. We originally used start time, so that we kept compatibility if the guest was later booted on older qemu which lacked alias support. We've since dropped support for such ancient QEMU, and also assign many other defaults at define time too. So I don't think there's any reason for aliases to be special cased and only assigned at start time.

If assigned at define time, it would be easy for applications to match up aliases with their original input config, and largely eliminate the need for any app specified alias.

(In reply to Daniel Berrange from comment #10)
> We could consider allowing a UUID to be recorded per device though - that
> has benefits over using a name, given its well-defined format and
> particularly its fixed size. IIRC, some hypervisor platforms do have a UUID
> associated with devices that could potentially be mapped in

That would work for us, we just need a way to uniquely identify a device. Actually one uuid could be even better than a plain name for that purpose.

We should keep in mind that (although it is by definition "unsupported") one of the reasons for wanting a stable name to refer to a device is so that it can be referenced in qemu commandline passthrough XML elements - if you're adding an option to the commandline for a specific device, you need to provide the qemu device id ( == libvirt device alias) in the arg that you add so the new option can be matched up with the device that gets it. A uuid would be nice in other ways, but it doesn't help in providing a stable "qemu device id" that can be reliably be referenced in a qemu:commandline element.

I also think that Michal's idea in Comment 9 is interesting, but way too complicated for what it adds (and I don't think it solves the qemu:commandline problem either).

Aside from the idea of just allowing the user to directly specify alias, I guess Dan's proposal to just select aliases at domain definition time gets the closest to solving the qemu:commandline problem. It does still create a "two step" process for anyone needing to reference the device though (including qemu:commandline) - first you need to add the device to the domain definition, then you need to do a dumpxml of the definition to learn what alias was assigned (and if you're using it for qemu:commandline, edit the domain a 2nd time to add the qemu:commandline element).

Personally, I don't have as much of a problem with the idea of allowing the user to specify the alias and expecting them to pick up the pieces when they make a bad (conflicting) choice. We have the same situation with tap and macvtap device names and people manage to deal with that, and we can prevent most problems by just keeping track of what names are in use and avoiding them during auto-assignment.

(BTW, yes, I know we don't want to actively encourage use of qemu:commandline. On the other hand, part of the workaround for not adding support for some of the more esoteric device options (e.g. device polling interval) has been to suggest using qemu:commandline to add the option if it's absolutely necessary. If that could be done in a way that didn't break as soon as another device of the same type was added/removed, there would be less room for rebuttal to that suggestion. To be clear, I agree with pushing back against adding explicit support for every conceivable qemu option, I just want to make it easier to advocate that position)

(In reply to Laine Stump from comment #13)
> We should keep in mind that (although it is by definition "unsupported") one
> of the reasons for wanting a stable name to refer to a device is so that it
> can be referenced in qemu commandline passthrough XML elements - if you're
> adding an option to the commandline for a specific device, you need to
> provide the qemu device id ( == libvirt device alias) in the arg that you
> add so the new option can be matched up with the device that gets it. A uuid
> would be nice in other ways, but it doesn't help in providing a stable "qemu
> device id" that can be reliably be referenced in a qemu:commandline element.
> 
> I also think that Michal's idea in Comment 9 is interesting, but way too
> complicated for what it adds (and I don't think it solves the
> qemu:commandline problem either).
> 
> Aside from the idea of just allowing the user to directly specify alias, I
> guess Dan's proposal to just select aliases at domain definition time gets
> the closest to solving the qemu:commandline problem. It does still create a
> "two step" process for anyone needing to reference the device though
> (including qemu:commandline) - first you need to add the device to the
> domain definition, then you need to do a dumpxml of the definition to learn
> what alias was assigned (and if you're using it for qemu:commandline, edit
> the domain a 2nd time to add the qemu:commandline element).

I see a possible problem with generating aliases at define time. Firstly, some configuration is finished (or realized) at the start time depending on current conditions. For instance, a domain can have an <interface type="network"/> but the network is configured so that it takes the next free physical NIC from a pool. Or, the network is configured so that it creates a tap device. Depending on these cases different aliases are assigned (in fact, the live XML is even altered in the first case because we're doing PCI assignment in fact).

And as for the qemu:commandline - I think that's just a matter of documenting it correctly that user provided aliases cannot be used for qemu:commandline.

(In reply to Michal Privoznik from comment #14)
> (In reply to Laine Stump from comment #13)
> > We should keep in mind that (although it is by definition "unsupported") one
> > of the reasons for wanting a stable name to refer to a device is so that it
> > can be referenced in qemu commandline passthrough XML elements - if you're
> > adding an option to the commandline for a specific device, you need to
> > provide the qemu device id ( == libvirt device alias) in the arg that you
> > add so the new option can be matched up with the device that gets it. A uuid
> > would be nice in other ways, but it doesn't help in providing a stable "qemu
> > device id" that can be reliably be referenced in a qemu:commandline element.
> > 
> > I also think that Michal's idea in Comment 9 is interesting, but way too
> > complicated for what it adds (and I don't think it solves the
> > qemu:commandline problem either).
> > 
> > Aside from the idea of just allowing the user to directly specify alias, I
> > guess Dan's proposal to just select aliases at domain definition time gets
> > the closest to solving the qemu:commandline problem. It does still create a
> > "two step" process for anyone needing to reference the device though
> > (including qemu:commandline) - first you need to add the device to the
> > domain definition, then you need to do a dumpxml of the definition to learn
> > what alias was assigned (and if you're using it for qemu:commandline, edit
> > the domain a 2nd time to add the qemu:commandline element).
> 
> I see a possible problem with generating aliases at define time. Firstly,
> some configuration is finished (or realized) at the start time depending on
> current conditions. For instance, a domain can have an <interface
> type="network"/> but the network is configured so that it takes the next
> free physical NIC from a pool. Or, the network is configured so that it
> creates a tap device. Depending on these cases different aliases are
> assigned (in fact, the live XML is even altered in the first case because
> we're doing PCI assignment in fact).

I'm not seeing the real problem here. If we assign an alias for that NIC at define time, we just have to honour that assigned alias, even when we resolve the specific type=network backend at start time. As long as the code is not relying on the particular naming scheme we should be fine.

> And as for the qemu:commandline - I think that's just a matter of
> documenting it correctly that user provided aliases cannot be used for
> qemu:commandline.

If they're using qemu:commandline to create extra devices, then they have full control over what id= they give to the device they create - no need for us todo anything special there.

Some patches posted on the list:

https://www.redhat.com/archives/libvir-list/2017-September/msg00765.html

I'd like the discussion to move there.

Despite me sending patches, I just realized that this approach might not be the perfect fit. As I understand the problem is that VDSM has a few device that they want to manage. So they construct some minimalistic domain XML, define it. At that point, libvirt adds handful of other devices (e.g. controllers). Now, if VDSM dumps the XML back, it's hard to match which devices they defined and which were added by libvirt. And this is where aliases won't help really. VDSM would still need some code that tries to match devices they provided with the ones in the domain XML. Libvirt generated aliases won't help.
IOW, it's not just a matter of changing already existing XML, it's also matter of defining new XML. In the former they can manage a list of current aliases and then match it with the ones after the edit, but still - how do you know which device/alias matches the device they provided and which were added by libvirt?

However, my approach from comment 9 would help. Just find the device that has the alias they provided initially.

I've proposed an alternative approach to the list:

https://www.redhat.com/archives/libvir-list/2017-September/msg01077.html

After some discussion upstream it has been agreed to have UUID per device. Patches are to be found here:

https://www.redhat.com/archives/libvir-list/2017-October/msg00075.html

Le sigh. Yet another approach was proposed, so I've implemented it:

https://www.redhat.com/archives/libvir-list/2017-October/msg00790.html

v2:

https://www.redhat.com/archives/libvir-list/2017-October/msg00985.html

I am proud to announce that I've just pushed the patches upstream:

commit 8bf6426d6eaf6fc2b4593927d2279ec36f75e0d3
Author:     Michal Privoznik <mprivozn>
AuthorDate: Fri Oct 20 16:19:07 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Mon Oct 23 09:02:37 2017 +0200

    news: Document user aliases
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit 7e939394b23845a72ddee969a69b2d0b071a08bf
Author:     Michal Privoznik <mprivozn>
AuthorDate: Fri Oct 20 16:48:14 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Mon Oct 23 09:02:30 2017 +0200

    tests: Test user set aliases for qemu
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit f3bc68e22177e745d470ccaaa23f776779b7e95e
Author:     Michal Privoznik <mprivozn>
AuthorDate: Thu Oct 19 08:39:40 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Mon Oct 23 09:01:46 2017 +0200

    qemu: Parse alias from inactive XMLs
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1434451
    
    This way users can uniquely identify devices at define time.
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit 93bc2c21267963eaea0183092aa03f31a3f7c79a
Author:     Michal Privoznik <mprivozn>
AuthorDate: Wed Oct 18 13:48:46 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Mon Oct 23 08:58:10 2017 +0200

    docs: Document user aliases
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit 0429e52f19d77752658cbc4b745103188650b2ea
Author:     Michal Privoznik <mprivozn>
AuthorDate: Wed Oct 18 13:12:08 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Mon Oct 23 08:56:55 2017 +0200

    conf: Format alias even for inactive XMLs
    
    We need to format alias even for inactive XMLs since that's the
    way how users are going to identify their devices.
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit 821b0b295d0dea21656a75bac34d4694ea28f4bd
Author:     Michal Privoznik <mprivozn>
AuthorDate: Tue Oct 17 13:13:08 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Mon Oct 23 08:53:51 2017 +0200

    qemuhotplugtest: Load active XML
    
    The point of this test is to load live XML and test hotplug. But
    even though the XMLs we are parsing are live, the parsing is done
    with VIR_DOMAIN_DEF_PARSE_INACTIVE flag.
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit a15c97f5e42324bb7be9c7afbac849b575a6926e
Author:     Michal Privoznik <mprivozn>
AuthorDate: Tue Oct 17 13:27:01 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Mon Oct 23 08:52:50 2017 +0200

    qemuxml2argvdata: Drop device aliases
    
    The qemuxml2argvtest expects the domain XMLs to be inactive ones.
    Therefore we should pass inactive XMLs.
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit 92f41b3297192c7e0e3ced63398e9c08f5f8cbd3
Author:     Michal Privoznik <mprivozn>
AuthorDate: Tue Oct 17 10:42:54 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Mon Oct 23 08:52:08 2017 +0200

    qemuDomainABIStabilityCheck: Check for memory aliases too
    
    Since we will be allowing users to set device aliases and memory
    devices are fragile when it comes to aliases we have to make sure
    they won't change during migration. Other devices should be fine.
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit e2797e3256cbfd43904a4edc3adc949b0bcdd342
Author:     Michal Privoznik <mprivozn>
AuthorDate: Wed Oct 18 17:46:18 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Mon Oct 23 08:52:01 2017 +0200

    conf: Validate user supplied aliases
    
    They have to be unique within the domain. As usual, backwards
    compatibility takes its price. In this particular situation we
    have a device that is represented twice in a domain and so is its
    alias.
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit c14f1ed20647f2c6d0ae14bf8c50234217d2a57b
Author:     Michal Privoznik <mprivozn>
AuthorDate: Wed Oct 18 14:59:01 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Sun Oct 22 13:49:46 2017 +0200

    conf: Parse user supplied aliases
    
    If driver that is calling the parse supports user supplied
    aliases, they can be parsed even for inactive XMLs. However, to
    avoid any clashes with aliases that libvirt generates, the user
    ones have to have "ua-" prefix.
    
    Note, that some drivers don't have notion of device aliases at
    all. Also, in order to support user supplied aliases some extra
    checks need to be done (e.g. during hotplug). Therefore we can't
    just enable this feature for all the drivers. Thus we need a flag
    that drivers set to tell parsing code that they can handle user
    supplied device aliases.
    
    Signed-off-by: Michal Privoznik <mprivozn>

commit ad30f069d108c9e6f30c2aec227d609df3b4e9af
Author:     Michal Privoznik <mprivozn>
AuthorDate: Fri Oct 20 13:24:41 2017 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Sun Oct 22 13:49:46 2017 +0200

    qemu_alias: Be more tolerant if alias don't follow our format
    
    When assigning alias to a device we usually iterate over other
    devices of its kind trying to find next index. We do this by
    stripping down the prefix and then parsing number at the end,
    Usually, if the prefix doesn't match the one we are expecting, we
    just continue with next iteration. Except for couple of
    functions: qemuGetNextChrDevIndex(),
    qemuAssignDeviceRedirdevAlias() and qemuAssignDeviceShmemAlias().
    
    Signed-off-by: Michal Privoznik <mprivozn>

v3.8.0-228-g8bf6426d6

Hi, Michal, when I verify this bug, there seems be some unexpected results as following when using alias for 'IDE' controller. While in this patch, that seems work, could you please help to check it first, thanks in advance?
https://www.redhat.com/archives/libvir-list/2017-October/msg00995.html

Test components version:
libvirt-3.9.0-1.el7.x86_64
qemu-kvm-rhev-2.10.0-4.el7.x86_64
kernel-3.10.0-768.el7.x86_64

Test steps:
1. Prepare 2 xml files, named 'vm1.xml' and 'vm2.xml', the following command 'cat' only shows the info of 'disk' and 'ide controller', 
as for detailed info, please refer to attachments
# ll /var/lib/libvirt/images/a.iso 
-rw-r--r--. 1 qemu qemu 0 Nov  2 16:57 /var/lib/libvirt/images/a.iso

# cat vm1.xml 
...
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/a.iso'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <shareable/>
      <alias name='ua-CDROM1'/>
    </disk>
...
    <controller type='ide' index='0'>
      <alias name='ua-IDE1'/>
    </controller>
...

# ll /var/lib/libvirt/images/b.iso
-rw-r--r--. 1 root root 0 Nov  7 11:37 /var/lib/libvirt/images/b.iso

# cat vm2.xml
... 
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/b.iso'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <shareable/>
      <alias name='ua-CDROM1'/>
    </disk>
...
    <controller type='ide' index='0'>
      <alias name='ide'/>
    </controller>
...

# diff vm1.xml vm2.xml 
2c2
<   <name>vm1</name>
---
>   <name>vm2</name>
41c41
<       <source file='/var/lib/libvirt/images/a.iso'/>
---
>       <source file='/var/lib/libvirt/images/b.iso'/>
50c50
<       <alias name='ua-IDE1'/>
---
>       <alias name='ide'/>

2. Define vm1 by 'vm1.xml' and try to start vm1
# virsh define vm1.xml ;virsh start vm1
Domain vm1 defined from vm1.xml

error: Failed to start domain vm1
error: internal error: qemu unexpectedly closed the monitor: 2017-11-07T03:37:48.594837Z qemu-kvm: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0)
2017-11-07T03:37:48.614633Z qemu-kvm: -device ide-cd,bus=ua-IDE1.0,unit=0,drive=drive-ua-CDROM1,id=ua-CDROM1: Bus 'ua-IDE1.0' not found

3. Define vm2 by 'vm2.xml' and try to start vm2, then check the qemu cmd line of vm2
# virsh define vm2.xml ;virsh start vm2
Domain vm2 defined from vm2.xml

Domain vm2 started

# ps -ef |grep vm2 |sed 's/-device/\n-device/g' |sed 's/-drive/\n-drive/g'
...
-drive file=/var/lib/libvirt/images/b.iso,format=raw,if=none,id=drive-ua-CDROM1,readonly=on,cache=none 
-device ide-cd,bus=ide.0,unit=0,drive=drive-ua-CDROM1,id=ua-CDROM1
...

4. Then I check another scenario, prepare 'vm3.xml', as for detailed info, please refer to attachments
# cat vm3.xml
...
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/a.iso'/>
      <target dev='hda' bus='virtio'/>
      <readonly/>
      <shareable/>
      <alias name='ua-CDROM1'/>
    </disk>
...
    <controller type='ide' index='0'>
      <alias name='ua-IDE1'/>
    </controller>
...

# virsh define vm3.xml ;virsh start vm3
Domain vm3 defined from vm3.xml

Domain vm3 started

# ps -ef |grep vm3 |sed 's/-device/\n-device/g' |sed 's/-drive/\n-drive/g'
...
-drive file=/var/lib/libvirt/images/a.iso,format=raw,if=none,media=cdrom,id=drive-ua-CDROM1,readonly=on,cache=none 
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-ua-CDROM1,id=ua-CDROM1 
...

Created attachment 1348811 [details]
vm_file_for_comment24

(In reply to jiyan from comment #24)
> Hi, Michal, when I verify this bug, there seems be some unexpected results
> as following when using alias for 'IDE' controller. While in this patch,
> that seems work, could you please help to check it first, thanks in advance?
> https://www.redhat.com/archives/libvir-list/2017-October/msg00995.html

Patch proposed upstream:

https://www.redhat.com/archives/libvir-list/2017-November/msg00355.html

I've pushed the patch upstream:

commit 9324f67a572f9b32f25bc088fb9f34e736edc612
Author:     Michal Privoznik <mprivozn>
AuthorDate: Thu Nov 9 13:34:43 2017 +0100
Commit:     Michal Privoznik <mprivozn>
CommitDate: Fri Nov 10 15:23:55 2017 +0100

    qemuBuildDriveDevStr: Prefer default aliases for IDE bus
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1434451
    
    When testing user aliases it was discovered that for 440fx
    machine type which has default IDE bus builtin, domain cannot
    start if IDE controller has the user provided alias. This is
    because for 440fx we don't put the IDE controller onto the
    command line (since it is builtin) and therefore any device that
    is plugged onto the bus must use the default alias.
    
    Signed-off-by: Michal Privoznik <mprivozn>


And here's the backport:

http://post-office.corp.redhat.com/archives/rhvirt-patches/2017-November/msg00296.html

To POST:

http://post-office.corp.redhat.com/archives/rhvirt-patches/2017-November/msg00470.html

Test env components version:
qemu-kvm-rhev-2.10.0-9.el7.x86_64
kernel-3.10.0-797.el7.x86_64
libvirt-3.9.0-3.el7.x86_64

Test scenario:
Scenario1: IDE Controller and IDE device
Step1. Prepare a xml file as following, both IDE controller and device have aliases
# cat test.xml
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/1.qcow2'/>
      <backingStore/>
      <target dev='hdc' bus='ide'/>
      <alias name='ua-ide-disk'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>
    <controller type='ide' index='0'>
      <alias name='ua-ide'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>

Step2. Define VM through xml file in Step1 and start VM， check qemu command line 
# virsh define test.xml 
Domain test defined from test.xml

# virsh start test
Domain test started

# ps -ef |grep test |sed 's/-device/\n-device/g'
-drive file=/var/lib/libvirt/images/1.qcow2,format=qcow2,if=none,id=drive-ua-ide-disk 
-device ide-hd,bus=ide.1,unit=0,drive=drive-ua-ide-disk,id=ua-ide-disk,bootindex=1 -netdev tap,fd=27,id=hostnet0

Result: In qemu cmdline, 'bus' info also shows as 'ide.1'

Scenario2: USB Controller and USB device
Scenario2-1: Start VM with aliases configured for USB controller and device
Step1. Prepare a xml file as following, both USB controller and device have aliases
# cat test.xml
    <controller type='usb' index='0' model='nec-xhci'>
      <alias name='ua-usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </controller>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/2.qcow2'/>
      <backingStore/>
      <target dev='hdb' bus='usb'/>
      <alias name='ua-usb-disk1'/>
      <address type='usb' bus='0' port='3'/>
    </disk>

Step2. Define VM through xml file in Step1 and start VM, check qemu command line 
# virsh define test.xml 
Domain test defined from test.xml

# virsh start test
Domain test started

# ps -ef |grep test |sed 's/-device/\n-device/g'
-device usb-storage,bus=ua-usb.0,port=3,drive=drive-ua-usb-disk1,id=ua-usb-disk1,removable=off

Scenario2-2: Cold-plug USB device with alias to VM with alias configure for USB controller
Step1. Prepare a shutdown VM and xml file used to attach USB device to VM
# virsh list --all |grep pc
 -     pc                             shut off

# virsh dumpxml pc --inactive|grep usb -A2
    <controller type='usb' index='0' model='nec-xhci'>
      <alias name='ua-usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </controller>

# cat usb-disk.xml 
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/2.qcow2'/>
      <target dev='hdb' bus='usb'/>
      <alias name='ua-usb-disk1'/>
    </disk>

Step2. Cold-plug USB device to VM
# virsh attach-device pc usb-disk.xml --config
Device attached successfully

# virsh dumpxml pc --inactive|grep usb -C6
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/2.qcow2'/>
      <target dev='hdb' bus='usb'/>
      <alias name='ua-usb-disk1'/>
      <address type='usb' bus='0' port='3'/>
    </disk>
    <controller type='usb' index='0' model='nec-xhci'>
      <alias name='ua-usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </controller>

Step3. Start VM, then check qemu cmdline and dumpxml file of VM
# virsh start pc
Domain pc started

# virsh dumpxml pc |grep usb -C5
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/2.qcow2'/>
      <backingStore/>
      <target dev='hdb' bus='usb'/>
      <alias name='ua-usb-disk1'/>
      <address type='usb' bus='0' port='3'/>
    </disk>
    <controller type='usb' index='0' model='nec-xhci'>
      <alias name='ua-usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </controller>

# ps -ef |grep pc |sed 's/-device/\n-device/g'
-device usb-storage,bus=ua-usb.0,port=3,drive=drive-ua-usb-disk1,id=ua-usb-disk1,removable=off

Scenario2-3: Hot-plug USB device with alias to VM with alias configure for USB controller
Step1. Prepare a running VM and xml file used to attach USB device to VM
# virsh list --all |grep pc
 20    pc                             running

# virsh dumpxml pc |grep usb -A2
    <controller type='usb' index='0' model='nec-xhci'>
      <alias name='ua-usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </controller>

# cat usb-disk.xml 
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/2.qcow2'/>
      <target dev='hdb' bus='usb'/>
      <alias name='ua-usb-disk1'/>
    </disk>

Step2. Hot-plug USB device to VM and check the dumpxml file 
# virsh attach-device pc usb-disk.xml 
Device attached successfully

# virsh dumpxml pc |grep "<disk" -A7
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/2.qcow2'/>
      <backingStore/>
      <target dev='hdb' bus='usb'/>
      <alias name='ua-usb-disk1'/>
      <address type='usb' bus='0' port='3'/>
    </disk>

Result: Both USB controller and device's aliases work nornally

Scenario3. Virtual disks with aliases
Scenario3-1: Start VM with aliases configured for floppy, cdrom, file 'disk' element 
Step1. Prepare a xml file describing virtual disks with aliases
# cat test.xml 
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/disk.qcow2'/>
      <target dev='hdb' bus='virtio'/>
      <alias name='ua-Disk'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/boot.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <shareable/>
      <alias name='ua-CDROM'/>
    </disk>
    <disk type='file' device='floppy'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/fd.img'/>
      <target dev='fdd' bus='fdc'/>
      <alias name='ua-floppy'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/secret.qcow2'/>
      <target dev='hde' bus='virtio'/>
      <encryption format='qcow'>  ==> Note: Define secret first
        <secret type='passphrase' uuid='ff4842e9-2e05-4e62-80a9-c5d3f5a7933d'/>
      </encryption>
      <alias name='ua-EncryptedDisk'/>
    </disk>

Step2. Define and start VM and check the qemu command line
# virsh define test.xml 
Domain test defined from test.xml

# virsh start test
Domain test started

# ps -ef |grep test |sed 's/-device/\n-device/g'
-device ide-hd,bus=ide.0,unit=0,drive=drive-ua-ide-disk1,id=ua-ide-disk1,bootindex=1 -drive file=/var/lib/libvirt/images/boot.iso,format=raw,if=none,id=drive-ua-CDROM,readonly=on,cache=none 
-device ide-cd,bus=ide.1,unit=0,share-rw=on,drive=drive-ua-CDROM,id=ua-CDROM -drive file=/var/lib/libvirt/images/disk.qcow2,format=qcow2,if=none,id=drive-ua-Disk 
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-ua-Disk,id=ua-Disk -drive file=/var/lib/libvirt/images/secret.qcow2,format=qcow2,if=none,id=drive-ua-EncryptedDisk 
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0xa,drive=drive-ua-EncryptedDisk,id=ua-EncryptedDisk -drive file=/var/lib/libvirt/images/fd.img,format=raw,if=none,id=drive-ua-floppy,cache=none -global isa-fdc.driveB=drive-ua-floppy -netdev tap,fd=27,id=hostnet0 

Scenario3-2: Hot-plug virtual disks with aliases to VM, since floppy and ide are not supported by hot-plugging
Step1. Prepare a running VM and the following 2 xml files
# virsh domstate pc
running

# cat disk.xml 
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/disk.qcow2'/>
      <target dev='hdb' bus='virtio'/>
      <alias name='ua-Disk'/>
    </disk>

# cat encrydisk.xml 
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/secret.qcow2'/>
      <target dev='hde' bus='virtio'/>
      <encryption format='qcow'>  ==> Note: Define secret first
        <secret type='passphrase' uuid='ff4842e9-2e05-4e62-80a9-c5d3f5a7933d'/>
      </encryption>
      <alias name='ua-EncryptedDisk'/>
    </disk>

Step2. Hot-plug virtual disks with aliases to VM and check the dumpxml file of VM
# virsh attach-device pc disk.xml 
Device attached successfully

# virsh attach-device pc encrydisk.xml 
Device attached successfully

# virsh dumpxml pc
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/disk.qcow2'/>
      <backingStore/>
      <target dev='hdb' bus='virtio'/>
      <alias name='ua-Disk'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/secret.qcow2'/>
      <backingStore/>
      <target dev='hde' bus='virtio'/>
      <encryption format='qcow'>
        <secret type='passphrase' uuid='ff4842e9-2e05-4e62-80a9-c5d3f5a7933d'/>
      </encryption>
      <alias name='ua-EncryptedDisk'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </disk>

Scenario4. Virtual networks with aliases
Scenario4-1: Start VM with aliases configured for interface element
Step1. Prepare a xml file describing virtual networks with aliases
    <interface type='ethernet'>
      <mac address='52:54:00:d6:c0:0b'/>
      <model type='virtio'/>
      <alias name='ua-CheckoutThisNIC'/>
    </interface>
    <interface type='server'>
      <mac address='52:54:00:22:c9:42'/>
      <source address='127.0.0.1' port='1234'/>
      <bandwidth>
        <inbound average='1234'/>
        <outbound average='5678'/>
      </bandwidth>
      <model type='rtl8139'/>
      <alias name='ua-WeCanAlsoDoServerMode'/>
    </interface>
    <interface type='client'>
      <mac address='52:54:00:8c:b1:f8'/>
      <source address='127.0.0.1' port='1234'/>
      <model type='rtl8139'/>
      <alias name='ua-AndAlsoClientMode'/>
    </interface>

Step2. Define and start VM and check the qemu command line
# virsh define test.xml 
Domain test defined from test.xml

# virsh start test
Domain test started

# ps -ef |grep test |sed 's/-device/\n-device/g'
-device virtio-net-pci,netdev=hostua-CheckoutThisNIC,id=ua-CheckoutThisNIC,mac=52:54:00:d6:c0:0b,bus=pci.0,addr=0x9 -netdev socket,listen=127.0.0.1:1234,id=hostua-WeCanAlsoDoServerMode 
-device rtl8139,netdev=hostua-WeCanAlsoDoServerMode,id=ua-WeCanAlsoDoServerMode,mac=52:54:00:22:c9:42,bus=pci.0,addr=0xa -netdev socket,connect=127.0.0.1:1234,id=hostua-AndAlsoClientMode 
-device rtl8139,netdev=hostua-AndAlsoClientMode,id=ua-AndAlsoClientMode,mac=52:54:00:8c:b1:f8,bus=pci.0,addr=0xb -chardev pty,id=charserial0 


Scenario4-2: Hot-plug virtual networks with aliases to VM, since hotplug of interface type of server or client is not implemented yet
Step1. Prepare a running VM and the following xml file
# virsh domstate pc
Running

# cat interface1.xml 
    <interface type='ethernet'>
      <mac address='52:54:00:d6:c0:0b'/>
      <model type='virtio'/>
      <alias name='ua-CheckoutThisNIC'/>
    </interface>

Step2. Hot-plug virtual network with aliases to VM and check the dumpxml file of VM
# virsh attach-device pc interface1.xml 
Device attached successfully

# virsh dumpxml pc
    <interface type='ethernet'>
      <mac address='52:54:00:d6:c0:0b'/>
      <target dev='vnet1'/>
      <model type='virtio'/>
      <alias name='ua-CheckoutThisNIC'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </interface>

All the results are expected, move this bug to verified.

Test more scenarios on libvirt-3.9.0-5.el7.x86_64

1. cold plug device with alias when the vm is running  will fail

# virsh start rhel7.4
Domain rhel7.4 started

# cat  interface2.xml
<interface type='network'>
 <source network='default' bridge='virbr0'/>
<alias name='ua-myinterface'/>
</interface>

# virsh attach-device rhel7.4 interface2.xml --config
error: Failed to attach device from interface2.xml
error: XML error: non unique alias detected: usb

# virsh dumpxml rhel7.4 --inactive | grep alias
==> no output

# virsh dumpxml rhel7.4 | grep alias
      <alias name='virtio-disk0'/>
      <alias name='virtio-disk1'/>
      <alias name='usb'/>
      <alias name='usb'/>
      <alias name='usb'/>
      <alias name='usb'/>
      <alias name='pci.0'/>
      <alias name='virtio-serial0'/>
      <alias name='scsi0'/>
      <alias name='serial0'/>
      <alias name='serial0'/>
      <alias name='channel0'/>
      <alias name='channel1'/>
      <alias name='input0'/>
      <alias name='input1'/>
      <alias name='input2'/>
      <alias name='sound0'/>
      <alias name='video0'/>
      <alias name='redir0'/>
      <alias name='redir1'/>
      <alias name='balloon0'/>

2. update disk's alias by update-device, return as succeed, but no changes actually 

# virsh dumpxml rhel7.4 | grep /disk -B7
....
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/2nddisk.qcow2'/>
      <backingStore/>
      <target dev='vdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </disk>

# cat  disk.xml
<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/2nddisk.qcow2'/>
      <backingStore/>
      <target dev='vdb' bus='virtio'/>
      <alias name='ua-mydisk'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </disk>

# virsh update-device rhel7.4  disk.xml
Device updated successfully

# virsh dumpxml rhel7.4 | grep /disk -B8
....
   <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/2nddisk.qcow2'/>
      <backingStore/>
      <target dev='vdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </disk>

3. Set alias in usb controllers as 'ua-usb1', 'ua-usb2', 'ua-usb3', 'ua-usb4', guest fail to start

# virsh edit rhel7.4
<controller type='usb' index='0' model='ich9-ehci1'>
      <alias name='ua-usb1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <alias name='ua-usb2'/>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <alias name='ua-usb3'/>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <alias name='ua-usb4'/>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    </controller>

# virsh start rhel7.4
error: Failed to start domain rhel7.4
error: internal error: qemu unexpectedly closed the monitor: 2017-12-11T01:55:23.789432Z qemu-kvm: -device ich9-usb-uhci1,masterbus=ua-usb2.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5: USB bus 'ua-usb2.0' not found

Serail and console device also share the same alias generated by libivrt, but when set in xml as different ones, the console's alias will be override.

    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
      <alias name='ua-myserial'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
      <alias name='ua-myconsole'/>
    </console>

# virsh dumpxml rhel7.4 | grep /console -B9
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
      <alias name='ua-myserial'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
      <alias name='ua-myserial'/>
    </console>

4. Set alias for pci-root controller, it exposed in the xml, but not in the qemu command line. It may be no sense to support this, suggest to ignore the setting in xml.

# virsh dumpxml rhel
...
 <controller type='pci' index='0' model='pci-root'>
      <alias name='ua-MYPCIROOT'/>
    </controller>
...

Hi Michal, Please help to check comment 30 ~ comment 32 for the 4 issues, Thank you very much!

(In reply to yalzhang from comment #30)
> Test more scenarios on libvirt-3.9.0-5.el7.x86_64
> 
> 1. cold plug device with alias when the vm is running  will fail
> 
> # virsh start rhel7.4
> Domain rhel7.4 started
> 
> # cat  interface2.xml
> <interface type='network'>
>  <source network='default' bridge='virbr0'/>
> <alias name='ua-myinterface'/>
> </interface>
> 
> # virsh attach-device rhel7.4 interface2.xml --config
> error: Failed to attach device from interface2.xml
> error: XML error: non unique alias detected: usb
> 
> # virsh dumpxml rhel7.4 --inactive | grep alias
> ==> no output
> 
> # virsh dumpxml rhel7.4 | grep alias
>       <alias name='virtio-disk0'/>
>       <alias name='virtio-disk1'/>
>       <alias name='usb'/>
>       <alias name='usb'/>
>       <alias name='usb'/>
>       <alias name='usb'/>
>       <alias name='pci.0'/>
>       <alias name='virtio-serial0'/>
>       <alias name='scsi0'/>
>       <alias name='serial0'/>
>       <alias name='serial0'/>
>       <alias name='channel0'/>
>       <alias name='channel1'/>
>       <alias name='input0'/>
>       <alias name='input1'/>
>       <alias name='input2'/>
>       <alias name='sound0'/>
>       <alias name='video0'/>
>       <alias name='redir0'/>
>       <alias name='redir1'/>
>       <alias name='balloon0'/>
> 

Unfortunately, I am unable to reproduce this. Can you please attach debug logs?

> 2. update disk's alias by update-device, return as succeed, but no changes
> actually 
> 
> # virsh dumpxml rhel7.4 | grep /disk -B7
> ....
>     <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2'/>
>       <source file='/var/lib/libvirt/images/2nddisk.qcow2'/>
>       <backingStore/>
>       <target dev='vdb' bus='virtio'/>
>       <alias name='virtio-disk1'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x09'
> function='0x0'/>
>     </disk>
> 
> # cat  disk.xml
> <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2'/>
>       <source file='/var/lib/libvirt/images/2nddisk.qcow2'/>
>       <backingStore/>
>       <target dev='vdb' bus='virtio'/>
>       <alias name='ua-mydisk'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x09'
> function='0x0'/>
>     </disk>
> 
> # virsh update-device rhel7.4  disk.xml
> Device updated successfully
> 
> # virsh dumpxml rhel7.4 | grep /disk -B8
> ....
>    <disk type='file' device='disk'>
>       <driver name='qemu' type='qcow2'/>
>       <source file='/var/lib/libvirt/images/2nddisk.qcow2'/>
>       <backingStore/>
>       <target dev='vdb' bus='virtio'/>
>       <alias name='virtio-disk1'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x09'
> function='0x0'/>
>     </disk>

This is a bug. I've proposed patch for it here:

https://www.redhat.com/archives/libvir-list/2017-December/msg00451.html

(In reply to yalzhang from comment #31)
> 3. Set alias in usb controllers as 'ua-usb1', 'ua-usb2', 'ua-usb3',
> 'ua-usb4', guest fail to start
> 

This fail even without user aliases. Only with a different error message.

> 
> Serail and console device also share the same alias generated by libivrt,
> but when set in xml as different ones, the console's alias will be override.
> 

That is right and in fact expected behaviour. Due to some crazy backward compatibility, in some cases first serial and first console are the same and only device. It's documented here:

https://libvirt.org/formatdomain.html#elementCharSerialAndConsole

(In reply to yalzhang from comment #32)
> 4. Set alias for pci-root controller, it exposed in the xml, but not in the
> qemu command line. It may be no sense to support this, suggest to ignore the
> setting in xml.
> 

Not really. I mean, even though we don't put it onto qemu's command line the device is there. There's no harm in allowing users to set an alias to it. Just see the patches that caused this bug to move from ON_QA to POST again. They fix this issue you're mentioning.

Created attachment 1367753 [details]
log for "attach-device" with "--config" with alias when vm is running

# grep error libvirtd.log
2017-12-14 02:20:36.753+0000: 8196: error : virDomainDeviceDefValidateAliasesIterator:5560 : XML error: non unique alias detected: usb

The patch mention in comment 34 is pushed and will be picked by rebase:

commit d0204e373d8aec51b1fd63783eeaa9a2015832ac
Author:     Michal Privoznik <mprivozn>
AuthorDate: Wed Dec 13 15:12:01 2017 +0100
Commit:     Michal Privoznik <mprivozn>
CommitDate: Fri Jan 5 14:22:45 2018 +0100

    qemuDomainDiskChangeSupported: Forbid alias change
    
    Since we have user aliases it may happen that users want to
    change it using 'update-device'. Instead of ignoring it silently,
    error out loudly. Note that we don't limit the check just for
    "ua-" prefixes because users might try to change libvirt
    generated aliases too.
    
    Signed-off-by: Michal Privoznik <mprivozn>
    Reviewed-by: John Ferlan <jferlan>

For the usb issue mentioned above: can you please also attach the domain XML? It's not in the logs unfortunatelly.

Created attachment 1384655 [details]
guest xml when guest is running

# virsh list
 Id    Name                           State
----------------------------------------------------
 1     test                           running

# cat interface2.xml 
<interface type='network'>
 <source network='default' bridge='virbr0'/>
<alias name='ua-myinterface'/>
</interface>

# virsh attach-device test interface2.xml --config
error: Failed to attach device from interface2.xml
error: XML error: non unique alias detected: usb

# virsh dumpxml test --live > test.xml

Created attachment 1384656 [details]
log for "attach-device" with "--config" with alias when vm is running

(In reply to yalzhang from comment #40)
> Created attachment 1384656 [details]
> log for "attach-device" with "--config" with alias when vm is running

I'm still unable to reproduce on the current git. Can you please retest with the latest HEAD and see if it is still broken?

(In reply to Michal Privoznik from comment #41)
> (In reply to yalzhang from comment #40)
> > Created attachment 1384656 [details]
> > log for "attach-device" with "--config" with alias when vm is running
> 
> I'm still unable to reproduce on the current git. Can you please retest with
> the latest HEAD and see if it is still broken?

Yes, I can still reproduce it on latest libvirt-3.9.0-9.el7.x86_64, and upstream libvirt-4.1.0-1.el7.x86_64. Maybe you can login my host to check? ping me when you are available. Thank you!

Hi, Michal, I still can reproduce the 2nd issue in  https://bugzilla.redhat.com/show_bug.cgi?id=1434451#c30 in libvirt-3.9.0-12.el7.x86_64

# rpm -qa libvirt qemu-kvm-rhev kernel
libvirt-3.9.0-12.el7.x86_64
kernel-3.10.0-847.el7.x86_64
qemu-kvm-rhev-2.10.0-20.el7.x86_64

# virsh domstate test
shut off

# virsh start test
Domain test started

# virsh dumpxml test |grep "<disk" -A8
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.qcow2'/>
      <backingStore/>
      <target dev='hda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/one.raw'/>
      <backingStore/>
      <target dev='hdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </disk>

# cat hdb.xml 
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/one.raw'/>
      <target dev='hdb' bus='virtio'/>
      <alias name='ua-disk-update1'/>
    </disk>

# virsh update-device test hdb.xml 
Device updated successfully

# virsh dumpxml test |grep "<disk" -A8
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/RHEL-7.5-x86_64-latest.qcow2'/>
      <backingStore/>
      <target dev='hda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/one.raw'/>
      <backingStore/>
      <target dev='hdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </disk>

After discussion, this feature basically works, 2 failed issues in https://bugzilla.redhat.com/show_bug.cgi?id=1434451#c34 will be tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1543775 in RHEL7.6.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0704