> From: Anthony Liguori [mailto:anth...@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@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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
