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