[libvirt] [PATCH] qemu: Migrate at unlimited speed by default
Eric Blake
eblake at redhat.com
Mon Aug 6 14:10:46 UTC 2012
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 at redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120806/310b1712/attachment-0001.sig>
More information about the libvir-list
mailing list