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 1333290 - virt-manager fails to detect the bridge with bond enslaved
Summary: virt-manager fails to detect the bridge with bond enslaved
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-manager
Version: 6.7
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Pavel Hrdina
QA Contact: Virtualization Bugs
Yehuda Zimmerman
URL:
Whiteboard:
Depends On:
Blocks: 1269194 1359965 1364808
TreeView+ depends on / blocked
 
Reported: 2016-05-05 08:24 UTC by Jijesh Kalliyat
Modified: 2021-08-30 12:37 UTC (History)
14 users (show)

Fixed In Version: virt-manager-0.9.0-32.el6
Doc Type: Bug Fix
Doc Text:
All bridge network interfaces are now listed for new devices in virtual machines Previously, not all bridge network interfaces were listed when a device was added to a virtual machine. With this update, all bridge network interfaces are properly detected using data provided by the "libvirt" service. As a result, all bridge network interfaces known to "libvirt" are listed when a device is added to a virtual machine.
Clone Of:
Environment:
Last Closed: 2017-03-21 10:42:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
When bond0 is attached to the bridge (62.71 KB, image/png)
2016-05-05 08:24 UTC, Jijesh Kalliyat 		no flags Details
When em1 is attached to the bridge (65.16 KB, image/png)
2016-05-05 08:26 UTC, Jijesh Kalliyat 		no flags Details
ifcfg-* files (583 bytes, application/x-gzip)
2016-05-06 05:32 UTC, Jijesh Kalliyat 		no flags Details
pic-1 (148.15 KB, image/png)
2016-12-05 11:32 UTC, zhoujunqin 		no flags Details
pic-2 (110.27 KB, image/png)
2016-12-05 11:33 UTC, zhoujunqin 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2976971 0 None None None 2017-03-24 05:48:36 UTC
Red Hat Product Errata RHBA-2017:0686 0 normal SHIPPED_LIVE virt-manager bug fix update 2017-03-21 12:37:31 UTC

Description Jijesh Kalliyat 2016-05-05 08:24:56 UTC 
Created attachment 1154125 [details]
When bond0 is attached to the bridge

1) Description of problem:
virt-manager doesn't list the bridge devices when a bond interface is attached to it. 


2) Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server release 6.7
virt-manager-0.9.0-29.el6_7.1.x86_64


3) How reproducible:

For example, create a bond device ( bond0 = em1+em2 ) and attach it to a bridge, br0

# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.c81f66d066ad	no		bond0
virbr0		8000.525400700906	yes		virbr0-nic

Then open virt-manager GUI and try to create a VM using this bridge. Ideally the virt-manager should show up 'br0' device in the drop down list like  "Host device bond0 ( Bridge 'br0' ) , but this device doesn't appear in the device list as shown in the attached bond-br0.png

Note that the issue is seen only when a 'bond' device is attached to the bridge. Otherwise if a physical device ( eth0 or em1 etc )  is attached to br0 , virt-manager list the devices as expected - see em1-br0.png

4) Actual results:
virt-manager doesn't list the bridge devices if a bond device is attached to it. 


5) Expected results:
virt-manager should list the bridge devices when a bond device is attached to it.
Comment 1 Jijesh Kalliyat 2016-05-05 08:26:05 UTC 
Created attachment 1154126 [details]
When em1 is attached to the bridge
Comment 4 Jaroslav Suchanek 2016-05-05 13:10:01 UTC 
Might be a netcf issue.
Comment 5 Laine Stump 2016-05-05 16:25:25 UTC 
(In reply to Jaroslav Suchanek from comment #4)
> Might be a netcf issue.

If virt-manager is using only the results of queries to libvirt's virInterface* functions to create this list, then that is definitely the case.

Note that netcf requires for an interface's ifcfg filename to match the device name. So, for example, the ifcfg file for br0 must be called "ifcfg-br0" and the ifcfg file for bond0 must be called "ifcfg-bond0". Additionally, the DEVICE attribute must be set in every ifcfg file.

To help troubleshoot the exact cause:

1) please provide the output of "virsh iface-list --all" and "virsh iface-dumpxml br0"

2) Also, please attach a tarball of /etc/sysconfig/network-scripts/ifcfg-*
Comment 6 Jijesh Kalliyat 2016-05-06 05:30:14 UTC 
The configuration files follows the same naming, and the DEVICE attribute is also set in every ifcfg-* files. Please find the files attached for your reference. 

# virsh iface-list --all
Name                 State      MAC Address
--------------------------------------------
br0                  active     c8:1f:66:d0:66:ad
lo                   active     00:00:00:00:00:00

# virsh iface-dumpxml br0
<interface type='bridge' name='br0'>
  <protocol family='ipv4'>
    <ip address='10.65.232.2' prefix='22'/>
  </protocol>
  <protocol family='ipv6'>
    <ip address='2620:52:0:41e8:ca1f:66ff:fed0:66ad' prefix='64'/>
    <ip address='fe80::ca1f:66ff:fed0:66ad' prefix='64'/>
  </protocol>
  <bridge>
    <interface type='bond' name='bond0'>
      <bond>
        <interface type='ethernet' name='em1'>
          <mac address='c8:1f:66:d0:66:ad'/>
        </interface>
        <interface type='ethernet' name='em2'>
          <mac address='c8:1f:66:d0:66:ad'/>
        </interface>
      </bond>
    </interface>
  </bridge>
</interface>
Comment 7 Jijesh Kalliyat 2016-05-06 05:32:49 UTC 
Created attachment 1154476 [details]
ifcfg-* files
Comment 8 Laine Stump 2016-05-06 16:10:25 UTC 
Based on the response and my own experiments, this *doesn't* look like a netcf problem.

I tried similar configs on a Fedora 23 system and RHEL6; the newer virt-manager on F23 gives correct results in the list of possible connections for an interface, but my RHEL6 results were similar to yours (as a matter of fact, virt-manager also didn't show a simpler bridge that's connected directly to an ethernet either).

However, the output of virsh iface-list and virsh iface-dumpxml are all correct, and even virt-manager itself shows the bond-based bridge in the Connection details under "Network Interfaces". So apparently the code in RHEL6 virt-manager that compiles the list of possible connections is missing something that's fixed upstream.
Comment 9 nijin ashok 2016-06-08 19:30:46 UTC 
I have a customer who is interested to get this fixed on RHEL 6.x . The bug is not in 7.2 version.

Also when we create one VM with command line with the bridge (which is having port as bond), it will start to show bridge device in virt-manager for later VM creation.
Comment 10 XiaoyunHu 2016-06-14 09:17:04 UTC 
I can reproduce this bug with package:
virt-manager-0.9.0-31.el6.x86_64
libvirt-0.10.2-29.el6_5.14.x86_64

Steps:
1. launch virt-manager, click Edit-> Connection details-> Network Interfaces.
2. Click "+" button to add interface. Select "Bond" as Interface type, Click "Forward" button.
3. Fill name as "bond0", set start mode as none, tick "active now", set IP settings as IPv4:DHCP, bond mode as "active-backup", bond monitor mode as arpmon. set Interval as 100 ,validate mode active and target address as 192.168.50.1
4. Click "ok" and choose interfaces "eth1""eth2" to bond.
5. Click "finish" button and bond0 works well.
6. Back to Connection Details page and click "+" button to add interface.
7. Select "Bridge" as Interface type, Click "Forward" button.
8. Fill name as "br1", start mode as none, tick "active now", set IP settings as IPv4:dhcp, click bridge configure and untick Enable STP.
9. Choose bond0 as interface to bridge.
10. Click "finish" button and br1 works well.
11. Back to virt-manager main page and click Create a new virtual machine.
12. Fill name as "test" and select one way to install, in the final step click Advanced options, check drop list of network device.
13. Tick "Customize configuration before install", click "Finish". Check drop list of source device in NIC tab.

Result:
After step 12, "Host device bond0 (Bridge 'br0')" device doesn't appear in the device list.
After step 13, "Host device bond0 (Bridge 'br0')" device doesn't appear in the source device list.
Comment 18 zhoujunqin 2016-12-05 11:31:38 UTC 
Try to verify this bug with new build:
virt-manager-0.9.0-33.el6.x86_64
python-virtinst-0.600.0-30.el6.noarch

Steps:
1. launch virt-manager, click Edit-> Connection details-> Network Interfaces.
2. Click "+" button to add interface. Select "Bond" as Interface type, Click "Forward" button.
3. Fill name as "bond0", set start mode as none, tick "active now", set IP settings as IPv4:DHCP, others as default setting.
4. Click "ok" and choose interfaces "eth0""eth3" to bond.
5. Click "finish" button and bond0 works well.
6. Back to Connection Details page and click "+" button to add interface.
7. Select "Bridge" as Interface type, Click "Forward" button.
8. Fill name as "br0", start mode as none, tick "active now", set IP settings as IPv4:dhcp, click bridge configure and untick Enable STP.
9. Choose bond0 as interface to bridge.
10. Click "finish" button and br0 works well.
11. Back to virt-manager main page and click Create a new virtual machine.
12. Fill name as "test" and select one way to install, in the final step click Advanced options, check drop list of network device.
13. Tick "Customize configuration before install", click "Finish". Check drop list of source device in NIC tab.

Result:
After step 12, "Bridge br0:Host device bond0" device is showing in device list, see pic-1.
After step 13, "Bridge br0:Host device bond0" device is showing in device list, but device lists are different from pic-1, see pic-2.

Additional info: the list are same on rhel7.

So Pavel, please help me have a look, thanks.
Comment 19 zhoujunqin 2016-12-05 11:32:37 UTC 
Created attachment 1228027 [details]
pic-1
Comment 20 zhoujunqin 2016-12-05 11:33:39 UTC 
Created attachment 1228028 [details]
pic-2
Comment 21 Pavel Hrdina 2016-12-20 12:22:14 UTC 
Hi Junqin,

Yes, it's an inconsistency and could be fixed, but it's not definitely related to this BZ.  Please create a new BZ for the network list issue.

Pavel
Comment 22 zhoujunqin 2016-12-21 09:20:44 UTC 
(In reply to Pavel Hrdina from comment #21)
> Hi Junqin,
> 
> Yes, it's an inconsistency and could be fixed, but it's not definitely
> related to this BZ.  Please create a new BZ for the network list issue.
> 
> Pavel

Thanks for your reply, Pavel.
Since virt-manager can list the bridge with bond enslaved, move this bug to VERIFIED, and create a new bug 1406691 to track network list inconsistency issue, thanks.
Comment 26 errata-xmlrpc 2017-03-21 10:42:35 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.

https://rhn.redhat.com/errata/RHBA-2017-0686.html
Note You need to log in before you can comment on or make changes to this bug.