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

[Sheldon]

On 12/02/2013 10:48 PM, Laine Stump wrote:
> 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.
Thank Laine for elaborating it.
>
>>>> 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).
>


-- 
Sheldon Feng(冯少合)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center