Re: [libvirt] [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps
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.