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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list