Re: [Qemu-devel] [libvirt] [PATCH v4] XBZRLE delta for live migration of large memory apps

[Daniel P. Berrange]

On Wed, Aug 10, 2011 at 02:27:41PM -0500, Anthony Liguori wrote:
> On 08/10/2011 11:40 AM, Avi Kivity wrote:
> Instead of teaching management tools how to deal with all of these
> things, let's just fix this problem once.  It just takes:
> 
> a) A query-migration-caps command that returns a dict with two lists
> of strings.  Something like:
> 
> { 'execute': 'query-migration-caps' }
> { 'return' : { 'capabilities': [ 'xbzrle' ], 'current': [] } }
> 
> b) A set-migration-caps command that takes a list of strings.  It
> simply takes the intersection of the capabilities set with the
> argument and sets the current set to the result.  Something like:
> 
> { 'execute': 'set-migration-caps', 'arguments': { 'set': [ 'xbzrle' ] }}
> { 'return' : {} }

We have a number of commands to set migration parameters (bandwidth,
max downtime, etc). One thing that has always troubled me with this,
is that they are a global setting for QEMU, not simply the next
migration command. This is fine if you expect that only a single
'migrate' command will ever be invoked during the lifetime of QEMU,
but this doesn't hold true when we use 'migrate' as a means to
implement saving of snapshots/save-to-file, or "core" dumps.

For example, when libvirt does 'save to file', we want to set the
max bandwidth to unlimited for that, but we don't want that 'unlimited'
setting to apply to a future cross-host migration attempt. This means
we have to send three commands 

   migrate_set_speed 9223372036854775808
   migrate file:/some/file
   migrate_set_speed 33554432

it doubly sucks because there is no way to reset the migration speed
to the QEMU default, so we have to hardcoded (32 << 20) which is what
QEMU currently uses.

It would be more desirable if we could simply pass in the desired
speed, compression algorithm, max downtime, etc, as parameters to
the 'migrate' command.  And then have 'migrate_set_speed' only
affect the current active migration, not any future ones.

So a 'query-migration-caps' command is nice, but I think having a
set-migration-caps command is wrong. There should just be a 'caps'
parameter for 'migrate'.

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 :|