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