This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 693711

Summary: Libvirt does not allow several client to communicate with the host using the same bridge
Product: [Fedora] Fedora Reporter: Ralf Spenneberg <ralf>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 14CC: aquini, berrange, clalance, crobinso, itamar, jforbes, laine, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-24 17:39:01 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Ralf Spenneberg 2011-04-05 07:57:47 EDT
Description of problem:


Version-Release number of selected component (if applicable):

libvirt-0.8.3-4.fc14.x86_64

How reproducible:

Every time

Steps to Reproduce:
1. Create a virtual network virbr1
2. Create two guests, connect both to the virtual network
3. The mac address of the guest started first is copied to the virbr1. The second guests mac address is different.
4. Try to connect to the host from both guests. The second guest works. The first guest does not work because guest and host share the same mac address.
  
Actual results:
Communication between the first guest and the host is not possible.

Expected results:
Communication should be possible.

Additional info:
Comment 1 Laine Stump 2011-04-06 11:51:55 EDT
Could it be that the problem is caused by the MAC address of the bridge *changing* when the 2nd guest is started, thus confusing the 1st guest? What happens when you start only guest 1, or only guest 2? are both able to communicate with the host in those cases?

The way that a Linux bridge device works is that it always takes on the lowest numerical MAC address of all the interfaces that are directly connected to it. So, by definition, there is no problem with the MAC address of the guest's tap interface and the MAC address of the bridge matching - this is just how things work.

However, problems can arise if a new guest with a lower MAC address is started/attached to the bridge - the MAC address of the bridge changes, and this causes problems. (I haven't heard of it causing a loss of network connectvity though, only that it causes MS Windows guests to believe they've connected to a new network).

This has been solved upstream by creating a dummy tap device with a MAC address guaranteed lower than any guest tap, and connecting that tap to the bridge. This way the bridge has a MAC (required for forwarding to work), but the MAC never changes.

The upstream commit is:

commit 5754dbd56d4738112a86776c09e810e32f7c3224
Subject: Give each virtual network bridge its own fixed MAC address

It is in just-released libvirt-0.9.0, which will hopefully show up in the F14 virt-preview repo soon.

Please give that version of libvirt a try if you can.,
Comment 2 Fedora Admin XMLRPC Client 2011-09-22 13:55:51 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 3 Fedora Admin XMLRPC Client 2011-09-22 13:59:01 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 Fedora Admin XMLRPC Client 2011-11-30 14:54:46 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Fedora Admin XMLRPC Client 2011-11-30 14:56:56 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 6 Fedora Admin XMLRPC Client 2011-11-30 15:00:30 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Fedora Admin XMLRPC Client 2011-11-30 15:02:16 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Cole Robinson 2012-01-24 17:39:01 EST
Closing as INSUFFICIENT_DATA (and F14 is EOL)
Comment 9 Ralf Spenneberg 2012-01-25 01:09:38 EST
Sorry for not replying. It works fine on Fedora 16.