Bug 1621910 - virDomainUpdateDeviceFlags fails when alias is not specified
Summary: virDomainUpdateDeviceFlags fails when alias is not specified
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: Han Han
URL:
Whiteboard:
: 1585108 1621935 (view as bug list)
Depends On:
Blocks: 1565252 1615414
TreeView+ depends on / blocked
 
Reported: 2018-08-23 20:42 UTC by Arik
Modified: 2019-01-10 16:14 UTC (History)
10 users (show)

Fixed In Version: libvirt-4.5.0-9.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 09:58:28 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1585108 None CLOSED Update virtual interface with alias return success but no change 2019-07-08 09:38:24 UTC
Red Hat Bugzilla 1603133 None None None 2019-07-08 09:38:24 UTC
Red Hat Product Errata RHSA-2018:3113 None None None 2018-10-30 09:59:31 UTC

Internal Links: 1585108 1603133

Description Arik 2018-08-23 20:42:45 UTC
Description of problem:
Libvirt now requires the XML that is passed to virDomainUpdateDeviceFlags to include the device alias. This is problematic as it breaks for clients that use to pass an XML that does not include the device alias.

Version-Release number of selected component (if applicable):
libvirt-4.5.0-3.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a domain with CD-ROM device, for example:

    <disk type="file" device="cdrom" snapshot="no">
      <driver name="qemu" type="raw" error_policy="report"/>
      <source file="/rhev/data-center/mnt/str-03s1.rhev.lab.eng.brq.redhat.com:_iso_shared/0c78b4d6-ba00-4d3e-9f9f-65c7d5899d71/images/11111111-1111-1111-1111-111111111111/en_windows_10_enterprise_x64_dvd_6851151.iso" startupPolicy="optional"/>
      <target dev="hdc" bus="ide"/>
      <readonly/>
      <alias name="ua-9efb2a9a-c507-4409-9bfe-51bd2a48788c"/>
      <boot order="1"/>
    </disk>

2. Try to update the ISO of that CD-ROM device with virDomainUpdateDeviceFlags given, e.g., the following XML:

    <disk device="cdrom" type="file">
      <source file="/rhev/datacenter/mnt/10.35.1.90:_srv_iso/d11a48a1-2fd6-45fb-9648-ac8c29ec8804/images/11111111-1111-1111-1111-111111111111/Fedora-Server-dvd-x86_64-24-1.2.iso" />
      <target bus="ide" dev="hdc" />
    </disk>

Actual results:
The update fails:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 5033, in _changeBlockDev
    diskelem_xml, libvirt.VIR_DOMAIN_DEVICE_MODIFY_FORCE
  File "/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", line 98, in f
    ret = attr(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 130, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in wrapper
    return func(inst, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2772, in updateDeviceFlags
    if ret == -1: raise libvirtError ('virDomainUpdateDeviceFlags() failed', dom=self)
libvirtError: operation forbidden: changing device alias is not allowed

Expected results:
The device should point to the new ISO.

Additional info:
virDomainUpdateDeviceFlags worked with the "partial" XML in libvirt-3.9.0-14.el7_5.6.x86_64.

Comment 3 Han Han 2018-08-27 09:22:12 UTC
This error is introduced from:
commit 4ad54a417a1bbe10aeffcce783f4381d8d43f799
Author:     Michal Privoznik <mprivozn@redhat.com>
AuthorDate: Tue Jun 12 16:05:10 2018 +0200
Commit:     Michal Privoznik <mprivozn@redhat.com>
CommitDate: Wed Jun 27 16:43:09 2018 +0200

    conf: Forbid device alias change on device-update
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1585108
    
    When updating a live device users might pass different alias than
    the one the device has. Currently, this is silently ignored which
    goes against our behaviour for other parts of the device where we
    explicitly allow only certain changes and error out loudly on
    anything else.
    
    Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
    Reviewed-by: John Ferlan <jferlan@redhat.com>

See also:https://bugzilla.redhat.com/show_bug.cgi?id=1585108

Comment 4 Michal Privoznik 2018-08-27 13:15:41 UTC
I don't think this is a bug. If users pass new device XML that doesn't contain certain data (in this case device alias) then such XML must be treated as request to clear out respective data. For instance, when updating domain's interface leaving out <bandwidth/> is handled as request to clear out any QoS previously set.

The only thing we should do here is document this behaviour more accurately.

Comment 5 Michal Privoznik 2018-08-27 13:51:11 UTC
In fact, I've proposed a patch to the upstream lists that does just that:

https://www.redhat.com/archives/libvir-list/2018-August/msg01696.html

Comment 6 Arik 2018-08-27 14:05:44 UTC
(In reply to Michal Privoznik from comment #4)
> I don't think this is a bug. If users pass new device XML that doesn't
> contain certain data (in this case device alias) then such XML must be
> treated as request to clear out respective data. For instance, when updating
> domain's interface leaving out <bandwidth/> is handled as request to clear
> out any QoS previously set.

Expecting clients to provide all the properties and assuming that missing things are supposed to be cleared is a bit problematic for clients as it requires them to either be able to reconstruct the entire structure or cache the latest configuration and extract the relevant part from it.

We can introduce an API that enables changing the CD image with partial input, as done in bz 1576916 for hot-unplug devices. Something like "updateISO(alias, iso_path)". But I wonder how many more cases like these we would find.

> 
> The only thing we should do here is document this behaviour more accurately.

The problem is that RHV/oVirt was not prepared for this change and so existing instances of ovirt-engine in the field that don't provide the alias may interact with newer libvirt versions that require it as described in bz 1615414.

Maybe libvirt can distinguish between the case of a running VM from that of a VM that is only defined and keep ignoring missing aliases for running VMs? (as it should be clear that aliases cannot change for running VMs)

Comment 7 Michal Privoznik 2018-08-28 08:42:26 UTC
(In reply to Arik from comment #6)
> (In reply to Michal Privoznik from comment #4)
> > I don't think this is a bug. If users pass new device XML that doesn't
> > contain certain data (in this case device alias) then such XML must be
> > treated as request to clear out respective data. For instance, when updating
> > domain's interface leaving out <bandwidth/> is handled as request to clear
> > out any QoS previously set.
> 
> Expecting clients to provide all the properties and assuming that missing
> things are supposed to be cleared is a bit problematic for clients as it
> requires them to either be able to reconstruct the entire structure or cache
> the latest configuration and extract the relevant part from it.

Well, if missing information is not treated as request to unset, I'm not sure how such request would/should look like then. For inactive domains libvirt allows clearing out user alias (for live ones that is not possible yet because device aliases are given to qemu as unique IDs). This is achieved by providing the same device XML minus <alias/> line.

> 
> We can introduce an API that enables changing the CD image with partial
> input, as done in bz 1576916 for hot-unplug devices. Something like
> "updateISO(alias, iso_path)". But I wonder how many more cases like these we
> would find.

I don't think we need such API. DeviceUpdate() is just fine.

> 
> > 
> > The only thing we should do here is document this behaviour more accurately.
> 
> The problem is that RHV/oVirt was not prepared for this change and so
> existing instances of ovirt-engine in the field that don't provide the alias
> may interact with newer libvirt versions that require it as described in bz
> 1615414.
> 
> Maybe libvirt can distinguish between the case of a running VM from that of
> a VM that is only defined and keep ignoring missing aliases for running VMs?
> (as it should be clear that aliases cannot change for running VMs)

Well, they can't change now. And if we do relax the assumption here we will never teach users to provide full XML.

But why it is problematic for vdsm to provide full device XML?

Comment 8 Arik 2018-08-28 09:31:37 UTC
(In reply to Michal Privoznik from comment #7)
> (In reply to Arik from comment #6)
> > (In reply to Michal Privoznik from comment #4)
> > > I don't think this is a bug. If users pass new device XML that doesn't
> > > contain certain data (in this case device alias) then such XML must be
> > > treated as request to clear out respective data. For instance, when updating
> > > domain's interface leaving out <bandwidth/> is handled as request to clear
> > > out any QoS previously set.
> > 
> > Expecting clients to provide all the properties and assuming that missing
> > things are supposed to be cleared is a bit problematic for clients as it
> > requires them to either be able to reconstruct the entire structure or cache
> > the latest configuration and extract the relevant part from it.
> 
> Well, if missing information is not treated as request to unset, I'm not
> sure how such request would/should look like then. For inactive domains
> libvirt allows clearing out user alias (for live ones that is not possible
> yet because device aliases are given to qemu as unique IDs). This is
> achieved by providing the same device XML minus <alias/> line.

Can it be designed in a way that specifying an empty alias, i.e., <alias/>, is interpreted as "please clear the alias" while not specifying the alias element at all is interpreted as "please keep the alias as-is"?

> 
> > 
> > We can introduce an API that enables changing the CD image with partial
> > input, as done in bz 1576916 for hot-unplug devices. Something like
> > "updateISO(alias, iso_path)". But I wonder how many more cases like these we
> > would find.
> 
> I don't think we need such API. DeviceUpdate() is just fine.
> 
> > 
> > > 
> > > The only thing we should do here is document this behaviour more accurately.
> > 
> > The problem is that RHV/oVirt was not prepared for this change and so
> > existing instances of ovirt-engine in the field that don't provide the alias
> > may interact with newer libvirt versions that require it as described in bz
> > 1615414.
> > 
> > Maybe libvirt can distinguish between the case of a running VM from that of
> > a VM that is only defined and keep ignoring missing aliases for running VMs?
> > (as it should be clear that aliases cannot change for running VMs)
> 
> Well, they can't change now. And if we do relax the assumption here we will
> never teach users to provide full XML.
> 
> But why it is problematic for vdsm to provide full device XML?

So imagine that a request in the form of "please change CD of VM X to ISO image Y" arrives. We have two possible ways to provide a full device XML with ISO image Y:

1. Either ovirt-engine or VDSM need to construct it from scratch. Some properties are easy to create, like the 'source' element. Some are harder, like the boot element as it requires to know the boot order of all other devices of the VM or what was the boot order that was previously set for the CD-ROM device.

2. Either ovirt-engine or VDSM need to retrieve the previous configuration of the CD-ROM device and replace the 'file' attribute of the 'source' property. However, ovirt-engine doesn't know the domain XML. 
When it comes to VDSM, besides introducing additional complexity in VDSM code, VDSM would need some correlation logic in order to find the right device in the domain XML.  * We can introduce a verb in VDSM that is similar to what I proposed before (i.e., updateISO(vm_id, device_alias, iso_path)) which will do that, but I think that doing that in libvirt could be useful for other management applications with similar flows (e.g., kubevirt).

But really, I think that before thinking about "how to do it right" we should think of how to preserve backward-compatibility with ovirt-engine & vdsm versions that do not provide the alias, as this would break future update flows in oVirt (the hosts are upgraded first so they'll get a newer libvirt version and it would lead to the the issue described in bz 1615414).

Comment 9 Michal Privoznik 2018-08-29 15:39:10 UTC
(In reply to Arik from comment #8)
> (In reply to Michal Privoznik from comment #7)
> > (In reply to Arik from comment #6)
> > > (In reply to Michal Privoznik from comment #4)
> > > > I don't think this is a bug. If users pass new device XML that doesn't
> > > > contain certain data (in this case device alias) then such XML must be
> > > > treated as request to clear out respective data. For instance, when updating
> > > > domain's interface leaving out <bandwidth/> is handled as request to clear
> > > > out any QoS previously set.
> > > 
> > > Expecting clients to provide all the properties and assuming that missing
> > > things are supposed to be cleared is a bit problematic for clients as it
> > > requires them to either be able to reconstruct the entire structure or cache
> > > the latest configuration and extract the relevant part from it.
> > 
> > Well, if missing information is not treated as request to unset, I'm not
> > sure how such request would/should look like then. For inactive domains
> > libvirt allows clearing out user alias (for live ones that is not possible
> > yet because device aliases are given to qemu as unique IDs). This is
> > achieved by providing the same device XML minus <alias/> line.
> 
> Can it be designed in a way that specifying an empty alias, i.e., <alias/>,
> is interpreted as "please clear the alias" while not specifying the alias
> element at all is interpreted as "please keep the alias as-is"?

That would complicate our XML parsing beyond comfortable zone. The way we currently parse XML is we construct an XPATH and store whatever value we find. For instance, when parsing alias, we query for ./alias/@name and if the XPATH succeeds we store the alias in our internal structure. If we were to store the fact we've seen <alias/> but not @name (and in general every element/attribute) our internal structures would blow up.

> 
> > 
> > > 
> > > We can introduce an API that enables changing the CD image with partial
> > > input, as done in bz 1576916 for hot-unplug devices. Something like
> > > "updateISO(alias, iso_path)". But I wonder how many more cases like these we
> > > would find.
> > 
> > I don't think we need such API. DeviceUpdate() is just fine.
> > 
> > > 
> > > > 
> > > > The only thing we should do here is document this behaviour more accurately.
> > > 
> > > The problem is that RHV/oVirt was not prepared for this change and so
> > > existing instances of ovirt-engine in the field that don't provide the alias
> > > may interact with newer libvirt versions that require it as described in bz
> > > 1615414.
> > > 
> > > Maybe libvirt can distinguish between the case of a running VM from that of
> > > a VM that is only defined and keep ignoring missing aliases for running VMs?
> > > (as it should be clear that aliases cannot change for running VMs)
> > 
> > Well, they can't change now. And if we do relax the assumption here we will
> > never teach users to provide full XML.
> > 
> > But why it is problematic for vdsm to provide full device XML?
> 
> So imagine that a request in the form of "please change CD of VM X to ISO
> image Y" arrives. We have two possible ways to provide a full device XML
> with ISO image Y:
> 
> 1. Either ovirt-engine or VDSM need to construct it from scratch. Some
> properties are easy to create, like the 'source' element. Some are harder,
> like the boot element as it requires to know the boot order of all other
> devices of the VM or what was the boot order that was previously set for the
> CD-ROM device.
> 
> 2. Either ovirt-engine or VDSM need to retrieve the previous configuration
> of the CD-ROM device and replace the 'file' attribute of the 'source'
> property. However, ovirt-engine doesn't know the domain XML. 
> When it comes to VDSM, besides introducing additional complexity in VDSM
> code, VDSM would need some correlation logic in order to find the right
> device in the domain XML.

Isn't that what I've written user aliases for? I can even see it in the "Steps to Reproduce" section.

>  * We can introduce a verb in VDSM that is similar
> to what I proposed before (i.e., updateISO(vm_id, device_alias, iso_path))
> which will do that, but I think that doing that in libvirt could be useful
> for other management applications with similar flows (e.g., kubevirt).
> 
> But really, I think that before thinking about "how to do it right" we
> should think of how to preserve backward-compatibility with ovirt-engine &
> vdsm versions that do not provide the alias, as this would break future
> update flows in oVirt (the hosts are upgraded first so they'll get a newer
> libvirt version and it would lead to the the issue described in bz 1615414).

Yes and no. We don't have comfort of ABI/API instability. Once we introduce an API we have to make sure it behaves the same across all the releases. Even if its behaviour turns out to be buggy. That's why libvirt always has to ask whether something is the right thing to do. Like in this case.

Anyway, I've written the patch that fixes this bug:

https://www.redhat.com/archives/libvir-list/2018-August/msg01858.html

Let's see what upstream thinks about this.

Comment 10 Arik 2018-08-29 16:11:19 UTC
(In reply to Michal Privoznik from comment #9)
> (In reply to Arik from comment #8)
> > (In reply to Michal Privoznik from comment #7)
> > > (In reply to Arik from comment #6)
> > > > (In reply to Michal Privoznik from comment #4)
> > > > > I don't think this is a bug. If users pass new device XML that doesn't
> > > > > contain certain data (in this case device alias) then such XML must be
> > > > > treated as request to clear out respective data. For instance, when updating
> > > > > domain's interface leaving out <bandwidth/> is handled as request to clear
> > > > > out any QoS previously set.
> > > > 
> > > > Expecting clients to provide all the properties and assuming that missing
> > > > things are supposed to be cleared is a bit problematic for clients as it
> > > > requires them to either be able to reconstruct the entire structure or cache
> > > > the latest configuration and extract the relevant part from it.
> > > 
> > > Well, if missing information is not treated as request to unset, I'm not
> > > sure how such request would/should look like then. For inactive domains
> > > libvirt allows clearing out user alias (for live ones that is not possible
> > > yet because device aliases are given to qemu as unique IDs). This is
> > > achieved by providing the same device XML minus <alias/> line.
> > 
> > Can it be designed in a way that specifying an empty alias, i.e., <alias/>,
> > is interpreted as "please clear the alias" while not specifying the alias
> > element at all is interpreted as "please keep the alias as-is"?
> 
> That would complicate our XML parsing beyond comfortable zone. The way we
> currently parse XML is we construct an XPATH and store whatever value we
> find. For instance, when parsing alias, we query for ./alias/@name and if
> the XPATH succeeds we store the alias in our internal structure. If we were
> to store the fact we've seen <alias/> but not @name (and in general every
> element/attribute) our internal structures would blow up.
> 
> > 
> > > 
> > > > 
> > > > We can introduce an API that enables changing the CD image with partial
> > > > input, as done in bz 1576916 for hot-unplug devices. Something like
> > > > "updateISO(alias, iso_path)". But I wonder how many more cases like these we
> > > > would find.
> > > 
> > > I don't think we need such API. DeviceUpdate() is just fine.
> > > 
> > > > 
> > > > > 
> > > > > The only thing we should do here is document this behaviour more accurately.
> > > > 
> > > > The problem is that RHV/oVirt was not prepared for this change and so
> > > > existing instances of ovirt-engine in the field that don't provide the alias
> > > > may interact with newer libvirt versions that require it as described in bz
> > > > 1615414.
> > > > 
> > > > Maybe libvirt can distinguish between the case of a running VM from that of
> > > > a VM that is only defined and keep ignoring missing aliases for running VMs?
> > > > (as it should be clear that aliases cannot change for running VMs)
> > > 
> > > Well, they can't change now. And if we do relax the assumption here we will
> > > never teach users to provide full XML.
> > > 
> > > But why it is problematic for vdsm to provide full device XML?
> > 
> > So imagine that a request in the form of "please change CD of VM X to ISO
> > image Y" arrives. We have two possible ways to provide a full device XML
> > with ISO image Y:
> > 
> > 1. Either ovirt-engine or VDSM need to construct it from scratch. Some
> > properties are easy to create, like the 'source' element. Some are harder,
> > like the boot element as it requires to know the boot order of all other
> > devices of the VM or what was the boot order that was previously set for the
> > CD-ROM device.
> > 
> > 2. Either ovirt-engine or VDSM need to retrieve the previous configuration
> > of the CD-ROM device and replace the 'file' attribute of the 'source'
> > property. However, ovirt-engine doesn't know the domain XML. 
> > When it comes to VDSM, besides introducing additional complexity in VDSM
> > code, VDSM would need some correlation logic in order to find the right
> > device in the domain XML.
> 
> Isn't that what I've written user aliases for? I can even see it in the
> "Steps to Reproduce" section.

Right, which was a great thing (user-aliases). But unfortunately, we cannot guarantee that user-aliases are used until we drop the support for cluster levels 4.1 and below in oVirt/RHV. Then we can simplify things by counting on user-aliases (that we started using in 4.2). 

> 
> >  * We can introduce a verb in VDSM that is similar
> > to what I proposed before (i.e., updateISO(vm_id, device_alias, iso_path))
> > which will do that, but I think that doing that in libvirt could be useful
> > for other management applications with similar flows (e.g., kubevirt).
> > 
> > But really, I think that before thinking about "how to do it right" we
> > should think of how to preserve backward-compatibility with ovirt-engine &
> > vdsm versions that do not provide the alias, as this would break future
> > update flows in oVirt (the hosts are upgraded first so they'll get a newer
> > libvirt version and it would lead to the the issue described in bz 1615414).
> 
> Yes and no. We don't have comfort of ABI/API instability. Once we introduce
> an API we have to make sure it behaves the same across all the releases.
> Even if its behaviour turns out to be buggy. That's why libvirt always has
> to ask whether something is the right thing to do. Like in this case.
> 
> Anyway, I've written the patch that fixes this bug:
> 
> https://www.redhat.com/archives/libvir-list/2018-August/msg01858.html
> 
> Let's see what upstream thinks about this.

Well, I'll try not to take the 'lazy users' part personally :)
Thanks

Comment 13 Han Han 2018-09-19 08:24:01 UTC
From the codes we know that only live update with disk,graphic,net could reach the changed code of logic. So I will test with following scenarios:
1. Live update disk with same/different/empty alias
2. Live update graphic
3. Live update net interface with same/different/empty alias

Expect that all live update with same/empty alias will success, with different alias will fail.

Setup steps:
Prepare a running VM with following xml:
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/boot.iso'/>
      <backingStore/>
      <target dev='sdb' bus='scsi'/>
      <readonly/>
      <alias name='ua-cdrom'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>

    <graphics type='spice' port='5900' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
      <image compression='off'/>
    </graphics>

    <interface type='bridge'>
      <mac address='52:54:00:8f:1c:36'/>
      <source bridge='switch'/>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>



1. Live update disk with same/different/empty alias
1.a Disk xml with same alias
# cat cdrom-same.xml 
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/boot-nbd.iso'/>
      <backingStore/>
      <target dev='sdb' bus='scsi'/>
      <readonly/>
      <alias name='ua-cdrom'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
# virsh update-device A cdrom-same.xml           
Device updated successfully

Check VM dumpxml:
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/boot-nbd.iso'/>
      <backingStore/>
      <target dev='sdb' bus='scsi'/>
      <readonly/>
      <alias name='ua-cdrom'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>


1.b Disk xml with empty alias:
# cat cdrom-empty.xml
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <backingStore/>
      <target dev='sdb' bus='scsi'/>
      <readonly/>
    </disk>
# virsh update-device A cdrom-empty.xml 
Device updated successfully

Check VM dumpxml:
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <backingStore/>
      <target dev='sdb' bus='scsi' tray='open'/>
      <readonly/>
      <alias name='ua-cdrom'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>


1.c Disk xml with different alias:
# cat cdrom-diff.xml                   
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/boot-nbd.iso'/>
      <backingStore/>
      <target dev='sdb' bus='scsi'/>
      <readonly/>
      <alias name='ua-diff'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>

# virsh update-device A cdrom-diff.xml 
error: Failed to update device from cdrom-diff.xml
error: operation forbidden: changing device alias is not allowed

Check vm disk xml:
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <backingStore/>
      <target dev='sdb' bus='scsi' tray='open'/>
      <readonly/>
      <alias name='ua-cdrom'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>



2. Graphic update
# cat graphic.xml      
    <graphics type='spice' port='5901' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
      <image compression='off'/>
      <alias name='ua-AAAA'/>
    </graphics>
# virsh update-device A graphic.xml   
Device updated successfully

Check graphic xml:
    <graphics type='spice' port='5900' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
      <image compression='off'/>
    </graphics>

It is not equal to the new graphic xml due to the same port.



3.Network update
3.a Network xml of same alias
# cat net-same.xml 
    <interface type='bridge'>
      <mac address='52:54:00:8f:1c:36'/>
  <bandwidth>
    <inbound average='1000' peak='5000' burst='5120'/>
  </bandwidth>
      <source bridge='switch'/>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
# virsh update-device A net-same.xml
Device updated successfully

Check vm network xml:
    <interface type='bridge'>
      <mac address='52:54:00:8f:1c:36'/>
      <source bridge='switch'/>
      <bandwidth>
        <inbound average='1000' peak='5000' burst='5120'/>
      </bandwidth>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>


3.b Network xml with different alias
# cat net-diff.xml
    <interface type='bridge'>
      <mac address='52:54:00:8f:1c:36'/>
  <bandwidth>
    <inbound average='900' peak='5000' burst='5120'/>
  </bandwidth>
      <source bridge='switch'/>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <alias name='ua-net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

# virsh update-device A net-diff.xml 
error: Failed to update device from net-diff.xml
error: operation forbidden: changing device alias is not allowed

Check vm network xml:
    <interface type='bridge'>
      <mac address='52:54:00:8f:1c:36'/>
      <source bridge='switch'/>
      <bandwidth>
        <inbound average='1000' peak='5000' burst='5120'/>
      </bandwidth>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>


3.c Network empty xml
# cat net-empty.xml 
    <interface type='bridge'>
      <mac address='52:54:00:8f:1c:36'/>
  <bandwidth>
    <inbound average='800' peak='5000' burst='5120'/>
  </bandwidth>
      <source bridge='switch'/>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

# virsh update-device A net-empty.xml 
Device updated successfully

Check vm network xml:
    <interface type='bridge'>
      <mac address='52:54:00:8f:1c:36'/>
      <source bridge='switch'/>
      <bandwidth>
        <inbound average='800' peak='5000' burst='5120'/>
      </bandwidth>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>


Except graphic, disk and network works as expected.

Comment 15 errata-xmlrpc 2018-10-30 09:58:28 UTC
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/RHSA-2018:3113

Comment 16 Michal Privoznik 2018-11-07 09:59:55 UTC
*** Bug 1621935 has been marked as a duplicate of this bug. ***

Comment 17 Michal Privoznik 2019-01-10 16:14:36 UTC
*** Bug 1585108 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.