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?)