Re: [Planning for Xen-4.6] Migration v2

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 26/11/14 08:09, Olaf Hering wrote:
> On Tue, Nov 25, Andrew Cooper wrote:
>
>> The purpose of this email is to plan how to progress the migrationv2
>> series through to being merged.  I believe I have CC'd everyone with a
>> specific interest in this area, but apologies if I have missed anyone.
> While you mow that lawn,

Lawns cease to be called lawns when they get this gnarly.  Paddock
perhaps? :)

> did you guys think of handling downtime of the
> migrated VM?

This again is in contradiction to the primary purpose of "Make something
which is no less functional than legacy migration".  Having said that,
migration downtime is an area will be looking into in XenServer,
although at the moment the bottlenecks are elsewhere in the system.

> I added some knobs to abort migration in a very libxc
> specific way. What I would like to see is a simple user interface for
> virsh/xl to control the downtime. See the thread "limit downtime during
> life migration from xl/virsh":
>
> http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html

The v2 code is substantially more efficient than the legacy code.  It
makes fewer hypercalls, it doesn't attempt to map frames its not
planning to send, or frames which it knows doesn't exist, it makes an
order of magnitude fewer syscalls as part of actually moving data.  Side
by side in otherwise identical situations, v2 is noticeably faster than
legacy.  A gut feel on small VMs during dev testing would be between 1/4
and 1/3rd faster, but we also have various measurements at a higher
level which show an improvement all round.  In particular, total time to
suspend a 128GB HVM guest is down by 60% when the *only* different in
the system is the algorithm used in libxenguest.

Also, the current knobs in migration v2 are different.  Legacy has max
iterations and max factor as knobs, (where max factor is frankly a
ludicrous parameter in my opinion), and replaced with a dirty threshold
in v2.  v2 currently has these values hard coded to 5 iterations and 50
(or fewer) dirty frames before pause.  This has proved to be better

It is certainly my hope going forward that different knobs can be
exposed.  One thing I think would be interesting is some proper
calculations of the delta in the dirty set, and offering a threshold
which chooses between "pause and complete" or "abort the migration and
complain that the VM is too active"

~Andrew