[libvirt] [question] We can create two network of one same linux bridge or local ethernet. It is a bug?

[Laine Stump]

On 12/02/2013 11:52 AM, Daniel P. Berrange wrote:
> On Sat, Nov 30, 2013 at 07:30:03PM +0800, Sheldon wrote:
>>> We can create two network of one same linux bridge or local ethernet:
>> This is not harmful.
>> But I wonder should this case is allowed?  Why?
> It should probably be rejected as invalid.


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.

>>> virsh # net-list --all
>>> Name State Autostart Persistent
>>> ----------------------------------------------------------
>>> br1 active yes yes
>>> br2 active yes yes
>>> default active yes yes
>>>
>>> virsh # net-dumpxml br1
>>> <network>
>>> <name>br1</name>
>>> <uuid>d5410814-1bea-b10d-04b8-9fbd3a1cfc65</uuid>
>>> <forward mode='bridge'/>
>>> <bridge name='br0' />
>>> </network>
>>>
>>> virsh # net-dumpxml br2
>>> <network>
>>> <name>br2</name>
>>> <uuid>99f20705-57cd-da31-f193-d13af4158792</uuid>
>>> <forward mode='bridge'/>
>>> <bridge name='br0' />
>>> </network>
>>>
>>> virsh # net-list --all
>>> Name State Autostart Persistent
>>> ----------------------------------------------------------
>>> br0 active yes yes
>>> br1 active yes yes
>>> default active yes yes
>>>
>>> virsh # net-dumpxml br0
>>> <network>
>>> <name>br0</name>
>>> <uuid>a35c840a-9bdc-070d-43f5-8e834040aa42</uuid>
>>> <forward dev='eth0' mode='bridge'>
>>> <interface dev='eth0'/>
>>> </forward>
>>> </network>
>>>
>>> virsh # net-dumpxml br1
>>> <network>
>>> <name>br1</name>
>>> <uuid>f1c87b80-2dfc-2a71-3fb6-56ef83daf29a</uuid>
>>> <forward dev='eth0' mode='bridge'>
>>> <interface dev='eth0'/>
>>> </forward>
>>> </network>

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