On 12/02/2013 11:52 AM, Daniel P. Berrange wrote: In the end, these "unmanaged" (by libvirt) networks are just describing where to connect the guests to, providing a persistent name for a particular network connection so that the underlying network implementation can change without needing to modify the guest config; they aren't doing anything to change the configuration of the bridge they point to, or any firewall rules or dhcp/dns server related to it. So allowing multiple networks to point to the same bridge doesn't create any bad situations, and I can actually think of a place where it would be useful. Let's say you have defined two networks, "engineering" and "sales" that are currently connected to the same network due to limitations in your physical network - simple enough, just define two networks that both point to the same bridge device. Then one day you get around to setting up a 2nd physical network and plugging your host into it - just change the definition of one of the networks to the new bridge and restart the guests (someday it would be nice if virNetworkUpdateFlags() could handle changing the bridge device of a network without restarting it). This same situation can't be handled with portgroups on a single network, though. This case is also harmless, since bridge mode of macvtap allows multiple connections to the same device. It is true, though, that when forward mode='passthrough', there would be problems if two networks tried to use the same physical device at the same time. However I think that the proper solution to that problem isn't to disallow listing of the same physdevs in multiple networks, but instead to keep a *global* (to libvirt) in-use count for all physdevs. In this way, the same pool of SRIOV VFs could be provided for multiple networks (e.g., a mode='passthrough *and* a mode='hostdev' network) and those networks could all safely share from that pool. (An example of the usefulness of this would be the case where you had some guests that required the extra bit of performance required by PCI passthrough of a physical device, and some guests could get by okay with macvtap in passthrough mode (and maybe still others could live with macvtap in one of it's shared modes).