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

> 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.