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

[Anthony Liguori]

On 08/08/2011 09:39 AM, Avi Kivity wrote:
>> The other option is to allow 1-off compression algorithms in the form
>> of plugins. I think in this case, plugins are a pretty good compromise
>> in terms of isolating complexity while allowing something that at
>> least works very well for one particular type of workload.
>
> I think you underestimate the generality of XBZRLE (or maybe I'm
> overestimating it?).

This is really my fundamental concern.  When it comes to something that 
we have to support for a very long time, no one should be estimating 
anything.  We should make these decisions based on an awful lot of 
analysis on a wide variety of workloads.

It's hard to do this in QEMU today because we don't have a module 
mechanism to make it easy for users to try out new things without fully 
committing to including something in the tree.

But I don't think that's the root of the problem I have.  I really am 
just extremely reluctant to commit to something that we have to support 
forever.

Thinking more about it though, I think there can be another 
solution--feature negotiation.

I view adding feature negotiation as a pre-requisite to adding any type 
of transport compression such as XBZRLE.  That will let us support 
migration to older QEMUs and also to eventually remove XBZRLE if we 
decide it doesn't make sense anymore.

Regards,

Anthony Liguori

> It's not reasonable to ask users to match a
> compression algorithm to their workload; most times they won't be
> interacting with the host at all. We need compression to be enabled at
> all time, turning itself off if it finds it isn't effective so it can
> consume less cpu.
>