On 08/03/2012 12:16 PM, Jiri Denemark wrote:
Previously, qemu did not respond to monitor commands during migration
if
the limit was too high. This prevented us from raising the limit
earlier. The qemu issue seems to be fixed (according to my testing) and
we may remove the 32Mb/s limit.
---
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_domain.h | 5 ++---
src/qemu/qemu_migration.c | 4 ++--
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 86f0265..a54df2f 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -217,7 +217,7 @@ static void *qemuDomainObjPrivateAlloc(void)
if (!(priv->cons = virConsoleAlloc()))
goto error;
- priv->migMaxBandwidth = QEMU_DOMAIN_DEFAULT_MIG_BANDWIDTH_MAX;
+ priv->migMaxBandwidth = QEMU_DOMAIN_MIG_BANDWIDTH_MAX;
This says that new libvirt will unconditionally try to use unlimited
bandwidth, instead of the qemu default of 32Mbps-limited bandwidth, in
all cases where the user does not additionally provide their own limiting.
Is that a backwards-incompatible change? Could there be an existing
client relying on the default limiting that will now be swamped by
libvirt being faster? Or is it a bug fix, where things will now just
operate faster by default, and people that care about limiting are not
impacted because they already had an explicit limit?
I think it is the latter (a bug fix - no one that cares about limiting
should be relying on defaults), so after the discussion we've had in
this thread, I'm okay giving:
ACK.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org