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.  It should also be
safe as the function pretty much amounts to NOP if no QoS is requested and the
new behaviour should not be any worse than before if it is.

Signed-off-by: Pavel Mores <pmo...@redhat.com>
---
 src/network/bridge_driver.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 72220e1c64..c8f7f07acb 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,11 @@ 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

Reply via email to