[libvirt] [PATCH] network: differentiate macvtap/bridge from host-bridge based networks

Ján Tomko jtomko at redhat.com
Fri Mar 18 09:17:54 UTC 2016


On Fri, Mar 11, 2016 at 11:13:50AM -0500, Laine Stump wrote:
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1316465
> 
> An attempt to simplify the code for the VIR_NETWORK_FORWARD_BRIDGE
> case of networkUpdateState in commit b61db335 (first in release
> 1.2.14) resulted in networks based on macvtap bridge mode being
> erroneously marked as inactive any time libvirtd was restarted.
> 
> The problem is that the original code had differentiated between a
> network using tap devices to connect to an existing host-bridge device
> (forward mode of VIR_NETWORK_FORWARD_BRIDGE and a non-NULL
> def->bridge), and one using macvtap bridge mode to connect to any
> ethernet device (still forward mode VIR_NETWORK_FORWARD_BRIDGE, but
> null def->bridge), but the changed code assumed that all networks with
> VIR_NETWORK_FORWARD_BRIDGE were tap + host-bridge networks, so a null
> def->bridge was interpreted as "inactive".
> 
> This patch restores the original code in networkUpdateState, as well
> as

"as well as" usually means the commit could be split up -
one for the regression introduced by b61db335 and one for starting the 
<forward mode="bridge"> networks with <pf>.

> fixing two other pre-existing similar problems - the cases for
> VIR_NETWORK_FORWARD_BRIDGE in both networkStartNetwork and
> networkShutdownNetwork have always made the same mistake - treating
> macvtap-bridge-mode networks as tap+host-bridge.
> ---
>  src/network/bridge_driver.c | 31 +++++++++++++++++++++----------
>  1 file changed, 21 insertions(+), 10 deletions(-)

ACK

Jan




More information about the libvir-list mailing list