Bug 895294
Summary: | vmUpdateDevice fails when nic has boot order set | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Antoni Segura Puimedon <asegurap> | |
Component: | libvirt | Assignee: | Laine Stump <laine> | |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | |
Severity: | medium | Docs Contact: | ||
Priority: | high | |||
Version: | 6.4 | CC: | abaron, acathrow, bazulay, cpelland, cwei, danken, dyuan, iheim, italkohe, jdenemar, jiahu, jkt, jsvarova, laine, lnovich, lpeer, mzhan, pkrempa, ydu | |
Target Milestone: | rc | Keywords: | Upstream, ZStream | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Linux | |||
Whiteboard: | network | |||
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 08:38:09 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1003934 |
Description
Antoni Segura Puimedon
2013-01-15 01:32:53 UTC
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 |