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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list