Open Stack

On Sun, Feb 01, 2015 at 03:03:45PM -0700, David Medberry wrote:
> I'll second much of what Rob said:
> API that indicated how many live-migrations (l-m) were going would be good.
> API that told you what progress (and start time) a given l-m had made would
> be great.
> API to cancel a given l-m would also be great. I think this is a preferred
> approach over an auto timeout (it would give us the tools we need to
> implement an auto timeout though.)
> 
> I like the idea of trying auto-convergence (and agree it should be flavor
> feature and likely not the default.) I suspect this one needs some testing.
> It may be fine to automatically do this if it doesn't actually throttle the
> VM some 90-99% of the time.  (Presumably this could also increase the max
> downtime between cutover as well as throttling the vm.)

For reference the auto-convergance code in QEMU is this commit

  http://git.qemu.org/?p=qemu.git;a=commit;h=7ca1dfad952d8a8655b32e78623edcc38a51b14a

If the migration operation is making good progress, it does not have any
impact on the guest. Periodically it checks the data transfer progress and
if the guest has dirtied more than 50% of the pages than were transferred
it'll start throttling. It throttles by simplying preventing the guest
vCPUs from running for a period of time. So the guest will obviously get
a performance drop, but the migration is more likely (but not guaranteed)
to succeed.

>From the QEMU level you can actually enable this on the fly it seems, but
libvirt only lets it be set at startup of migration.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|