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

[Anthony Liguori]

On 08/11/2011 03:17 AM, Avi Kivity wrote:
>> 3) a management tool should be able to query the source and
>> destination, and then enable xzbrle if both sides support it.
>>
>> You can argue that (3) could be static. A command could be added to
>> toggle it dynamically through the monitor.
>>
>> But no matter what, someone has to touch libvirt and any other tool
>> that works with QEMU to make this thing work. But this is a general
>> problem. Any optional change to the migration protocol has exactly the
>> same characteristics whether it's XZBRLE, XZBRLE v2 (if there is a
>> v2), ASN.1, or any other form of compression that rolls around.
>
> If we have two-way communication we can do this transparently in the
> protocol itself.

Yes.  This should be one of the initial caps to introduce.

>> 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' : {} }
>>
>> c) An internal interface to register a capability and an internal
>> interface to check if a capability is currently enabled. The xzbrle
>> code just needs to disable itself if the capability isn't set.
>>
>> Then we teach libvirt (and other tools) to query the caps list on the
>> source, set the destination, query the current set on the destination,
>> and then set that set on the source.
>
> This is only if the capability has no side effect.

Right, it can't change the output of any monitor commands or anything 
like that.  It's strictly about the encoding of the wire protocol which 
ought to be transparent to libvirt.

>> As we introduce new things, like the next great compression protocol,
>> or ASN.1, we don't need to touch libvirt again. libvirt can still know
>> about the caps and selectively override QEMU if it's so inclined but
>> it prevents us from reinventing the same mechanisms over and over again.
>
> Right.
>
>>
>> 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.
>
> Okay, as long as we have someone willing to implement it.

Sounds like a good hackathon project :-)

Regards,

Anthony Liguori