[libvirt] [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps
Avi Kivity
avi at redhat.com
Thu Aug 11 08:17:09 UTC 2011
On 08/10/2011 10:27 PM, Anthony Liguori wrote:
>> This may be acceptable, wait until the entire migration cluster is
>> xzbrle capable before enabling it. If not, add a monitor command.
>
>
> 1) xzbrle needs to be disabled by default. That way management tools
> don't unknowingly enable it by not passing -no-xzbrle.
We could hook it to -M, though it's a bit gross. Otherwise we need to
document this clearly in the management tool author's guide.
>
> 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.
>
> 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.
>
> 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.
--
error compiling committee.c: too many arguments to function
More information about the libvir-list
mailing list