To fix the actual bug, it was necessary to make networkPlugBandwidth() be
called also for 'bridge'-type networks implemented using macvtap's
'bridge'
mode (previously it was only called for those implemented on top of an
existing bridge).
However, it seems beneficial to call it for other network types as well,
at least because it removes an inconsistency in types of bandwidth
configuration changes permissible in inactive and active domain configs.
Signed-off-by: Pavel Mores <pmores(a)redhat.com>
---
src/network/bridge_driver.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 3b70e52afd..513ae59e68 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -4571,8 +4571,6 @@ networkAllocatePort(virNetworkObjPtr obj,
return -1;
}
- if (networkPlugBandwidth(obj, &port->mac, port->bandwidth,
&port->class_id) < 0)
- return -1;
break;
case VIR_NETWORK_FORWARD_HOSTDEV: {
@@ -4637,8 +4635,6 @@ networkAllocatePort(virNetworkObjPtr obj,
}
}
- if (networkPlugBandwidth(obj, &port->mac, port->bandwidth,
&port->class_id) < 0)
- return -1;
break;
}
@@ -4736,6 +4732,9 @@ networkAllocatePort(virNetworkObjPtr obj,
return -1;
}
+ if (networkPlugBandwidth(obj, &port->mac, port->bandwidth,
&port->class_id) < 0)
+ return -1;
+
if (virNetworkObjMacMgrAdd(obj, driver->dnsmasqStateDir,
port->ownername, &port->mac) < 0)
return -1;
--
2.24.1