On Wed, Aug 10, 2011 at 02:27:41PM -0500, Anthony Liguori wrote:
> On 08/10/2011 11:40 AM, Avi Kivity wrote:
> 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 wi
On 08/11/2011 12:16 PM, Daniel P. Berrange wrote:
On Thu, Aug 11, 2011 at 11:17:09AM +0300, Avi Kivity wrote:
> 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 com
On Thu, Aug 11, 2011 at 11:17:09AM +0300, Avi Kivity wrote:
> 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 defa
On 08/08/2011 05:04 PM, Daniel P. Berrange wrote:
My main concern with all these scenarios where libvirt touches the
actual data stream though is that we're introducing extra data copies
into the migration path which potentially waste CPU cycles.
If QEMU can directly XBZRLE encode data into the F
On Mon, Aug 08, 2011 at 08:29:51AM -0500, Anthony Liguori wrote:
> On 08/08/2011 03:42 AM, Shribman, Aidan wrote:
> >Subject: [PATCH v4] XBZRLE delta for live migration of large memory apps
> >From: Aidan Shribman
> >
> >By using XBZRLE (Xor Binary Zero Run-Length-Encoding) we can reduce VM
> >dow
