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?)
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.
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:
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.
(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?)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list