Bug 895294 - vmUpdateDevice fails when nic has boot order set
vmUpdateDevice fails when nic has boot order set
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.4
Unspecified Linux
high Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
network
: Upstream, ZStream
Depends On:
Blocks: 1003934
  Show dependency treegraph
 
Reported: 2013-01-14 20:32 EST by Antoni Segura Puimedon
Modified: 2013-11-21 03:38 EST (History)
19 users (show)

See Also:
Fixed In Version: libvirt-0.10.2-19.el6
Doc Type: Bug Fix
Doc Text:
Updating a network interface using virDomainUpdateDeviceFlags API failed when a boot order was set for that interface. The update failed even if the boot order was set in the provided device XML. virDomainUpdateDeviceFlags API has been fixed to correctly parse boot order specification from the provided device XML and updating network interfaces with boot orders now works as expected.
Story Points: ---
Clone Of:
: 906446 (view as bug list)
Environment:
Last Closed: 2013-11-21 03:38:09 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 11148 None None None Never

  None (edit)
Description Antoni Segura Puimedon 2013-01-14 20:32:53 EST
Description of problem:
When creating a VM with a specific boot order set for a nic, attempting to use the new 3.2 feature of vmUpdateDevice will result in an exception

Version-Release number of selected component (if applicable):4.10.3


How reproducible: 100%


Steps to Reproduce:
1. Create a VM with a nic. Set boot order=1 to it.
2. Go to the host (cmdline) and do:
vdsClient -s 0 vmUpdateDevice vmId deviceType=interface alias=net0 linkActive=False
  
Actual results:
A libvirt Exception
Thread-1516::DEBUG::2013-01-15 02:22:02,673::libvirtvm::1660::vm.Vm::(setLinkAndNetwork) vmId=`b04b6a8c-3471-45ae-8c98-1aa9801cb2ad`::Request failed: <interface type="bridge">
        <address bus="0x00" domain="0x0000" function="0x0" slot="0x04" type="pci"/>
        <mac address="00:1a:4a:a8:7a:09"/>
        <model type="virtio"/>
        <source bridge="rhevm"/>
        <filterref filter="vdsm-no-mac-spoofing"/>
        <link state="up"/>
        <boot order="1"/>
</interface>
Traceback (most recent call last):
  File "/usr/share/vdsm/libvirtvm.py", line 1656, in setLinkAndNetwork
    libvirt.VIR_DOMAIN_AFFECT_LIVE)
  File "/usr/share/vdsm/libvirtvm.py", line 539, in f
    ret = attr(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 111, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1742, in updateDeviceFlags
    if ret == -1: raise libvirtError ('virDomainUpdateDeviceFlags() failed', dom=self)
libvirtError: this function is not supported by the connection driver: cannot modify network device boot index setting

Expected results:
The VM nic link goes down.

Additional info:
Comment 1 Antoni Segura Puimedon 2013-01-14 20:36:53 EST
The fix for this will probably be to filter out all the nic attributes from the xml generation except the basic ones:
- address
- mac address
- model
- source
- filter (At the moment we do not support changing it through vmUpdateDevice, but that might change in the future, so I would not drop it from this whitelist).
- link state.
Comment 3 Antoni Segura Puimedon 2013-01-17 08:08:22 EST
Made a patch to implement the whitelist:

http://gerrit.ovirt.org/#/c/11148/

Now the boot order is not passed anymore, but libvirt throws the same error:

Thread-130::DEBUG::2013-01-17 14:01:47,492::libvirtvm::1666::vm.Vm::(setLinkAndNetwork) vmId=`b04b6a8c-3471-45ae-8c98-1aa9801cb2ad`::Request failed: <interface type="bridge">
        <address bus="0x00" domain="0x0000" function="0x0" slot="0x06" type="pci"/>
        <mac address="00:1a:4a:a8:7a:08"/>
        <model type="virtio"/>
        <source bridge="rhevm"/>
        <filterref filter="vdsm-no-mac-spoofing"/>
        <link state="down"/>
</interface>
Traceback (most recent call last):
  File "/usr/share/vdsm/libvirtvm.py", line 1662, in setLinkAndNetwork
    libvirt.VIR_DOMAIN_AFFECT_LIVE)
  File "/usr/share/vdsm/libvirtvm.py", line 539, in f
    ret = attr(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 111, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1742, in updateDeviceFlags
    if ret == -1: raise libvirtError ('virDomainUpdateDeviceFlags() failed', dom=self)
libvirtError: this function is not supported by the connection driver: cannot modify network device boot index setting
Thread-130::DEBUG::2013-01-17 14:01:47,505::libvirtvm::1672::vm.Vm::(setLinkAndNetwork) vmId=`b04b6a8c-3471-45ae-8c98-1aa9801cb2ad`::Rolling back link and net for: net0
Traceback (most recent call last):
  File "/usr/share/vdsm/libvirtvm.py", line 1667, in setLinkAndNetwork
    raise SetLinkAndNetworkError(e.message)
SetLinkAndNetworkError: this function is not supported by the connection driver: cannot modify network device boot index setting
Thread-130::ERROR::2013-01-17 14:01:47,509::BindingXMLRPC::924::vds::(wrapper) libvirt error
Traceback (most recent call last):
  File "/usr/share/vdsm/BindingXMLRPC.py", line 919, in wrapper
    res = f(*args, **kwargs)
  File "/usr/share/vdsm/BindingXMLRPC.py", line 269, in vmUpdateDevice
    return vm.vmUpdateDevice(params)
  File "/usr/share/vdsm/API.py", line 380, in vmUpdateDevice
    return v.updateDevice(params)
  File "/usr/share/vdsm/libvirtvm.py", line 1718, in updateDevice
    return self._updateInterfaceDevice(params)
  File "/usr/share/vdsm/libvirtvm.py", line 1631, in _updateInterfaceDevice
    with self.setLinkAndNetwork(netDev, netConf, linkValue, network):
  File "/usr/lib64/python2.6/contextlib.py", line 16, in __enter__
    return self.gen.next()
  File "/usr/share/vdsm/libvirtvm.py", line 1674, in setLinkAndNetwork
    libvirt.VIR_DOMAIN_AFFECT_LIVE)
  File "/usr/share/vdsm/libvirtvm.py", line 539, in f
    ret = attr(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 111, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1742, in updateDeviceFlags
    if ret == -1: raise libvirtError ('virDomainUpdateDeviceFlags() failed', dom=self)
libvirtError: this function is not supported by the connection driver: cannot modify network device boot index setting
Comment 4 Laine Stump 2013-01-17 10:34:44 EST
An error about modifying boot order should only be raised if the new suggested boot order is different from the current boot order. You shouldn't need to filter it (or anything else) out of your device update if everything is being filled in from the current state of the device.

(Also, modifying filterref is already supported in upstream libvirt (1.0.1), so it will eventually make it into RHEL.)

Let me try to reproduce this.
Comment 5 Antoni Segura Puimedon 2013-01-17 10:42:08 EST
(In reply to comment #4)
> An error about modifying boot order should only be raised if the new
> suggested boot order is different from the current boot order. You shouldn't
> need to filter it (or anything else) out of your device update if everything
> is being filled in from the current state of the device.

I was attempting to workaround, but I agree that libvirt should not fire up an error unless a change is attempted.

> 
> (Also, modifying filterref is already supported in upstream libvirt (1.0.1),
> so it will eventually make it into RHEL.)

Sounds great! Does specifying it (without change) cause a problem like the one for boot order? If that is not the case, I could probably abandone my workaround patch completely, I guess.
> 
> Let me try to reproduce this.
Comment 6 Laine Stump 2013-01-17 11:32:34 EST
This is all caused by a bug in libvirt's parsing of device "info" (which includes the guest PCI address, boot order, and a couple of other things common to most/all devices). The result of this bug is that it's not filling in the bootIndex in the internal object representation of the device.

A fuller explanation of the cause is this:

When a complete domain is parsed, a global (to the domain) "bootMap" is passed down to the parse for each device; the bootMap is used to make sure that devices don't have conflicting settings for their boot orders.

When a single device is parsed by itself (as in the case of virDomainUpdateDeviceFlags), there is no global bootMap that would be appropriate to send, so NULL is sent instead. However, although the lowest level function that parses just the boot order *does* simply skip the sanity check in that case, the next higher level "virDomainDeviceInfoParseXML" function refuses to call down to the lower "virDomainDeviceBootParseXML". So, the boot order is never set in the "new" device object, and when it is compared to the original (which does have a boot order), they don't match.

The fix is to patch virDomainDeviceInfoParseXML to not care about bootMap. I just sent a 1 line patch upstream to fix it.
Comment 7 Laine Stump 2013-01-17 11:42:41 EST
(In reply to comment #5)

> > 
> > (Also, modifying filterref is already supported in upstream libvirt (1.0.1),
> > so it will eventually make it into RHEL.)
> 
> Sounds great! Does specifying it (without change) cause a problem like the
> one for boot order? If that is not the case, I could probably abandone my
> workaround patch completely, I guess.

Correct. You shouldn't need to do any filtering of the elements in the current device. If you do, that's a bug and should be fixed.
Comment 8 Laine Stump 2013-01-17 15:11:17 EST
I pushed the following upstream:

commit 877dab6ccf9ce79e28c1e5f9b70459a9f9a8a6c2
Author: Laine Stump <laine@laine.org>
Date:   Thu Jan 17 11:18:21 2013 -0500

    conf: don't fail to parse <boot> when parsing a single device
Comment 18 Hu Jianwei 2013-07-10 03:57:29 EDT
This bug reproduced on libvirt-0.10.2-18.el6_4.9.x86_64 version, but not reproduce on libvirt-0.10.2-19.el6.x86_64 version.

[root@dell-per415-05 ~]# rpm -q libvirt vdsm 
libvirt-0.10.2-19.el6.x86_64
vdsm-4.10.2-23.0.el6ev.x86_64

1. Added host1 to rhevm env, and create a vm with nic, and set "<boot order='1'/>" to the nic.

    <interface type='bridge'>
      <mac address='00:1a:4a:42:05:9f'/>
      <source bridge='rhevm'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <filterref filter='vdsm-no-mac-spoofing'/>
      <link state='up'/>
      <boot order='1'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

2. In host1, do below commands:
[root@dell-per415-05 ~]# vdsClient -s 0 list table
c1f00a80-85dc-4f1c-97f3-9db23d7081cb  12289  haw1                 Up 
[root@dell-per415-05 ~]# 
[root@dell-per415-05 ~]# vdsClient -s 0 vmUpdateDevice c1f00a80-85dc-4f1c-97f3-9db23d7081cb deviceType=interface alias=net0 linkActive=False 

...
{'nicModel': 'pv', 'macAddr': '00:1a:4a:42:05:9f', 'linkActive': False, 'network': 'rhevm', 'specParams': {}, 'bootOrder': '1', 'filter': 'vdsm-no-mac-spoofing', 'alias': 'net0', 'deviceId': '28acae46-2a38-47dd-820f-d4773cc25c57', 'address': {'slot': '0x03', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x0'}, 'device': 'bridge', 'type': 'interface', 'portMirroring': [], 'name': 'vnet0'}
...

3. In the guest, we can find the network down after setting linkActive=False, and fail to ping from other host to guest.

4. Set "linkActive=True" using the following command, the network will back.
[root@dell-per415-05 ~]# vdsClient -s 0 vmUpdateDevice c1f00a80-85dc-4f1c-97f3-9db23d7081cb deviceType=interface alias=net0 linkActive=True 
...
{'nicModel': 'pv', 'macAddr': '00:1a:4a:42:05:9f', 'linkActive': True, 'network': 'rhevm', 'specParams': {}, 'bootOrder': '1', 'filter': 'vdsm-no-mac-spoofing', 'alias': 'net0', 'deviceId': '28acae46-2a38-47dd-820f-d4773cc25c57', 'address': {'slot': '0x03', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x0'}, 'device': 'bridge', 'type': 'interface', 'portMirroring': [], 'name': 'vnet0'},
...

We can get expected result, changed to verified.
Comment 19 Dan Kenigsberg 2013-09-02 16:59:08 EDT
Would it be possible to backport this fix to el6.4? oVirt-3.3 would be much obliged if you do. Without it, ovirt-3.3 is unable to update properties of a vnic of a running VM (e.g. RHEV bug 1001001).
Comment 24 errata-xmlrpc 2013-11-21 03:38:09 EST
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.

http://rhn.redhat.com/errata/RHBA-2013-1581.html

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