On Tue, Dec 07, 2010 at 01:46:40AM -0500, Laine Stump wrote:
This is in reference to the following bugs that are filed against
RHEL, but applicable to all Linux distros:
https://bugzilla.redhat.com/show_bug.cgi?id=560994
https://bugzilla.redhat.com/show_bug.cgi?id=609463
"MAC address of virtual network bridge changes when TAP devices are
added/removed"
The problem is that the MAC address of a bridge that hasn't had its
address specifically set, will be set to the MAC address of the
first interface attached to it. If that interface later goes away,
it will be set to the MAC address of another attached interface.
Daniel's comments in the bug 1) state that the MAC address of a
bridge device must match the MAC address of one of the attached
interfaces, or no traffic will pass, and 2) suggest creating a dummy
interface that is created and used purely to set a fixed MAC address
that won't go away when any guest is destroyed (because it's not
associated with any guest.
I did some quick experimentation and found that:
1) It is possible to set a bridge's MAC address to something that
isn't the address of an attached interface (although the range of
numbers seems to be limited, at least when setting it using "ip link
set virbr0 address xx:xx:xx:xx:xx:xx - anything starting with less
than "B2" was rejected).
2) When a bridge's MAC address is set in that way, as Daniel says,
no traffic passes. (Why is that, anyway?)
A bridge device *must* have a MAC address that machines one of
its enslaved devices. It can't have its own MAC address. The
bridge will automatically obtain the MAC of the first interface
enslaved normally.
3) If I create a tap device, set a MAC address on it, attach it to
the bridge, and make sure the bridge is assigned that MAC address,
traffic does pass, and when guests are destroyed and restarted, the
MAC address of the bridge doesn't change.
You need to make sure the MAC address of the special TAP device is
numerically smaller than the MAC address of any normal VM TAP
device. This is fairly easy, since we now ensure all TAP devices
for VMs have 0xFE for their high byte. So the special device can
just have any value smaller than 0xFE (for values of 'any' which
are careful not to select a multicast MAC).
So it looks like this is a viable way to solve the problem. Before
digging into it, though, I thought I should ask if there are any
alternate ideas, or problems that anyone sees with this approach.
Also, I'm wondering where the name and MAC address of the dummy
interfaces should come from, and whether I need to worry about
storing them in the network XML. So far, this is what I think on
those topics:
You could make a case for including the MAC address in
the XML, describing it as the MAC address of the router. We
should definitely not include the interface name because that
is a Linux specific implementation details.
1) the MAC address can be autogenerated if it's not in the XML,
but
needs to be saved in the XML so that it's persistent across libvirtd
restarts.
2) the dummy interface name can just be some derivation of the
bridge device name ("virbr0-mac"?), and probably doesn't need to be
saved in the XML.
Agreed.
(Also, I just noticed the code that sets the first byte of the MAC
address of all tap interfaces being attached to virtual network
bridges to 0xFE. What's the story behind that? Does the bridge
always take the numerically lowest MAC that's currently connected?)
Yes. This is to guarnetee that all guest TAP devices have a MAC
that is higher than any physical NIC (no NIC vendor has a prefix
assigned with 0xFE or 0xFF)
Daniel