RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1003934 - vmUpdateDevice fails when nic has boot order set
Summary: vmUpdateDevice fails when nic has boot order set
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.4
Hardware: Unspecified
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
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)

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


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:1272 0 normal SHIPPED_LIVE Important: libvirt security and bug fix update 2013-09-19 22:02:43 UTC
oVirt gerrit 11148 0 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.

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

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.