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.

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

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.

(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.

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.

(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.

I pushed the following upstream:

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

    conf: don't fail to parse <boot> when parsing a single device

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.

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).

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