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 1596176 - Error message when restart libvirtd and a vm with interface connected to ovs bridge
Summary: Error message when restart libvirtd and a vm with interface connected to ovs ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.6
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1596628
TreeView+ depends on / blocked
 
Reported: 2018-06-28 11:38 UTC by Fangge Jin
Modified: 2019-04-03 11:48 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1596628 (view as bug list)
Environment:
Last Closed: 2019-04-03 11:48:42 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Fangge Jin 2018-06-28 11:38:18 UTC 
Description of problem:
Start a vm with interface connected to ovs bridge, then restart libvirtd. There will be error in libvirtd.log:
2018-06-28 09:36:16.124+0000: 18286: error : virNetDevBridgeRemovePort:743 : Unable to remove bridge ovs-system port vnet1: Operation not supported
/lib64/libvirt.so.0(virLogMessage+0x9f)[0x7fb478388f6f]
/lib64/libvirt.so.0(+0x14f73d)[0x7fb47835873d]
/lib64/libvirt.so.0(virRaiseErrorFull+0x264)[0x7fb478359944]
/lib64/libvirt.so.0(virReportSystemErrorFull+0x1c4)[0x7fb478359f04]
/lib64/libvirt.so.0(virNetDevBridgeRemovePort+0x190)[0x7fb4783973a0]
/usr/lib64/libvirt/connection-driver/libvirt_driver_network.so(+0x140d7)[0x7fb45eddd0d7]
/lib64/libvirt.so.0(virDomainNetNotifyActualDevice+0x22)[0x7fb47845bcb2]
/usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so(+0x105852)[0x7fb4235dd852]
/lib64/libvirt.so.0(+0x1d6cd5)[0x7fb4783dfcd5]
/lib64/libpthread.so.0(+0x7dd5)[0x7fb4756fbdd5]
/lib64/libc.so.6(clone+0x6d)[0x7fb475424ead]


Version-Release number of selected component (if applicable):
libvirt-4.4.0-2.virtcov.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Create a ovs network:
# virsh net-dumpxml ovs-net
<network>
  <name>ovs-net</name>
  <uuid>b174b6e9-a05c-480a-adb1-a185310079f1</uuid>
  <forward mode='bridge'/>
  <bridge name='ovsbr0'/>
  <virtualport type='openvswitch'/>
</network>

2.Start a vm with interface connected to ovs network:
    <interface type='network'>
      <mac address='52:54:00:a9:6d:05'/>
      <source network='ovs-net'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x13' function='0x0'/>
    </interface>

3.Restart libvirtd

Actual results:
Error in libvirtd.log when restart libvirtd

Expected results:
No error

Additional info:
Comment 2 Laine Stump 2018-07-01 23:23:27 UTC 
This is caused by libvirtd checking that each guest tap device is connected to the correct bridge. The problem is that it's doing this by retrieving the IFLA_MASTER for the tap with netlink, and for some reason IFLA_MASTER is always set to "ovs-system" for any tap that is attached to an OVS switch (rather than being set to the name of the switch itself, which is the case for normal Linux host bridges). libvirt thus thinks that the tap is connected to "ovs-system" rather than "ovsbr0", and tries to remove the device from ovs-system (using the standard SIOCBRDELIF ioctl, which would of course fail for an OVS switch even if we were giving it the correct name for the switch).
Comment 3 Laine Stump 2018-07-05 03:00:21 UTC 
The following 3 patches were pushed upstream (*after* the 4.5.0 release):

commit 032548c42af49d83b760a8b4c5a29dd78149ab7b
Author: Laine Stump <laine>
Date:   Sun Jul 1 19:24:19 2018 -0400

    util: new function virNetDevOpenvswitchInterfaceGetMaster()
    
commit 15072f3a97d8b55421fa418df58708e306d8813d
Author: Laine Stump <laine>
Date:   Sun Jul 1 19:27:17 2018 -0400

    util: add some debug log to virNetDevGetMaster

commit c17edaf7782d7a9b15940ac8422c1761e8f90902
Author: Laine Stump <laine>
Date:   Sun Jul 1 19:29:03 2018 -0400

    network: properly check for taps that are connected to an OVS bridge
Comment 5 RHEL Program Management 2019-04-03 11:48:42 UTC 
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Note You need to log in before you can comment on or make changes to this bug.