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@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org