Bug 1003934
| Summary: | vmUpdateDevice fails when nic has boot order set | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Idith Tal-Kohen <italkohe> |
| 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, asegurap, bazulay, cpelland, cwei, danken, dyuan, iheim, italkohe, jdenemar, jiahu, jkt, jsvarova, laine, lnovich, lpeer, mzhan, pkrempa, pm-eus, whuang, ydu |
| Target Milestone: | rc | Keywords: | Upstream, ZStream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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 18:08:33 UTC | Type: | --- |
| 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: | 895294 | ||
| Bug Blocks: | 1001001 | ||
|
Description
Idith Tal-Kohen
2013-09-03 14:28:37 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.
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.
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 |