Bug 1003934 - vmUpdateDevice fails when nic has boot order set
Summary: vmUpdateDevice fails when nic has boot order set
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.4
Hardware: Unspecified
OS: Linux
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
Keywords: Upstream, ZStream
Depends On: 895294
Blocks: 1001001
TreeView+ depends on / blocked
Reported: 2013-09-03 14:28 UTC by Idith Tal-Kohen
Modified: 2013-09-19 18:08 UTC (History)
22 users (show)

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.
Clone Of:
Last Closed: 2013-09-19 18:08:33 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:1272 normal SHIPPED_LIVE Important: libvirt security and bug fix update 2013-09-19 22:02:43 UTC
oVirt gerrit 11148 None None None Never

Description Idith Tal-Kohen 2013-09-03 14:28:37 UTC
This bug has been copied from bug #895294 and has been proposed
to be backported to 6.4 z-stream (EUS).

Comment 6 Hu Jianwei 2013-09-06 08:44:51 UTC
The bug can reproduce on libvirt-0.10.2-18.el6_4.9 version, but can not reproduce on libvirt-0.10.2-18.el6_4.10 version.


1. Added host to rhevm env, and create a guest with nic, and set "<boot order='1'/>" to the nic. Dump xml as below:
    <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'/>

2. In host, do below commands:
[root@dhcp-66-71-41 ~]# vdsClient -s 0 list table
59878e00-c9cd-4691-9fc3-46e9c047535b   4572  virt1                Up

[root@dhcp-66-71-41 ~]# vdsClient -s 0 vmUpdateDevice 59878e00-c9cd-4691-9fc3-46e9c047535b deviceType=interface alias=net0 linkActive=False
{'nicModel': 'pv', 'macAddr': '00:1a:4a:42:06:1d', 'linkActive': False, 'network': 'rhevm', 'specParams': {}, 'bootOrder': '1', 'filter': 'vdsm-no-mac-spoofing', 'alias': 'net0', 'deviceId': '0fc4a532-8c88-4345-ab57-ec1afa132be8', 'address': {'slot': '0x03', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x0'}, 'device': 'bridge', 'type': 'interface', 'portMirroring': [], 'name': 'vnet0'},

3. In this guest, the network was lost connection after the command.

4. In host, To change back the network.
[root@dhcp-66-71-41 ~]# vdsClient -s 0 vmUpdateDevice 59878e00-c9cd-4691-9fc3-46e9c047535b deviceType=interface alias=net0 linkActive=True
{'nicModel': 'pv', 'macAddr': '00:1a:4a:42:06:1d', 'linkActive': True, 'network': 'rhevm', 'specParams': {}, 'bootOrder': '1', 'filter': 'vdsm-no-mac-spoofing', 'alias': 'net0', 'deviceId': '0fc4a532-8c88-4345-ab57-ec1afa132be8', 'address': {'slot': '0x03', 'bus': '0x00', 'domain': '0x0000', 'type': 'pci', 'function': '0x0'}, 'device': 'bridge', 'type': 'interface', 'portMirroring': [], 'name': 'vnet0'}, 

5. In guest, network came back to normal, resumed the network connection.

We can get expected result using those command lines, so changed to verified.

Comment 8 errata-xmlrpc 2013-09-19 18:08:33 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.


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