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

> From: Anthony Liguori [mailto:anthony@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(a)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