Bug 1003934 - 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
: Upstream, ZStream
Depends On: 895294
Blocks: 1001001
  Show dependency treegraph
 
Reported: 2013-09-03 10:28 EDT by Idith Tal-Kohen
Modified: 2013-09-19 14:08 EDT (History)
22 users (show)

See Also:
Fixed In Version: libvirt-0.10.2-18.el6_4.10
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:
Environment:
Last Closed: 2013-09-19 14:08:33 EDT
Type: ---
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 Idith Tal-Kohen 2013-09-03 10:28:37 EDT
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 04:44:51 EDT
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.

Version:
libvirt-0.10.2-18.el6_4.10.x86_64
qemu-kvm-rhev-0.12.1.2-2.355.el6_4.8.x86_64
kernel-2.6.32-358.18.1.el6.x86_64
vdsm-4.10.2-24.1.el6ev.x86_64

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'/>
    </interface>

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 14:08:33 EDT
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/RHSA-2013-1272.html

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