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

[Shribman, Aidan]

> From: Anthony Liguori [mailto:anthony at codemonkey.ws]
> Sent: Wednesday, August 10, 2011 10:28 PM
> To: Avi Kivity
> Cc: Blue Swirl; Stefan Hajnoczi; Shribman, Aidan; qemu-devel
> Developers; libvir-list at redhat.com
> Subject: Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of
> large memory apps

> 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 may want to further sub-divide capabilities into categories:
{ 'execute': 'query-migration-caps' }
{ 'return' : 
  { 'encoding' : { 'current', 'asn.1', 'proto2', 'thrift', etc. } },
  { 'delta' : { 'xbzrle', "xdelta", ...} },
  { 'compression' : { 'snappy', 'lzo' } } }
This would help libvirt/management to select features automatically or manually (via UI) without having to 'understand' the any given capability meaning.

> Yes.  But that negotiation needs to become part of the "protocol" for
> migration.  In the absence of that negotiation, we need to use the wire
> protocol we use today.  We cannot have ad-hoc feature negotiation for
> every change we make to the wire protocol.

Agreed. Therefore caps plus xbzrle could be added before ASN.1/v1.0 without breaking anything as long as when 'set-migration-caps' is not issued Qemu uses the current protocol.

Aidan