On 08/11/2011 03:17 AM, Avi Kivity wrote:
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,
delta for live migration of
large memory apps
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'
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
> From: Anthony Liguori [mailto:anth...@codemonkey.ws]
> Sent: Wednesday, August 10, 2011 10:28 PM
> To: Avi Kivity
> Cc: Blue Swirl; Stefan Hajnoczi; Shribman, Aidan; qemu-devel
> Developers; libvir-l...@redhat.com
> Subject: Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live mi
On 08/10/2011 11:40 AM, Avi Kivity wrote:
On 08/10/2011 07:23 PM, Anthony Liguori wrote:
Right now we have capabilties in the form of -help output.
If -help says
-no-xzbrle disable xzbrle support
(or -migration-compression xzbrle=off, or something) that's sufficient
for management tools.
T
On 08/10/2011 07:23 PM, Anthony Liguori wrote:
Right now we have capabilties in the form of -help output.
If -help says
-no-xzbrle disable xzbrle support
(or -migration-compression xzbrle=off, or something) that's sufficient
for management tools.
This is static, not dynamic. You may attemp
On 08/10/2011 11:08 AM, Avi Kivity wrote:
On 08/10/2011 06:58 PM, Anthony Liguori wrote:
I don't think we should couple the two features together.
ASN.1 is orthogonal to capabilities.
Capabilities are a hard requirement before merging any new type of
compression algorithm IMO.
Right now we
On 08/10/2011 06:58 PM, Anthony Liguori wrote:
I don't think we should couple the two features together.
ASN.1 is orthogonal to capabilities.
Capabilities are a hard requirement before merging any new type of
compression algorithm IMO.
Right now we have capabilties in the form of -help out
On 08/10/2011 10:12 AM, Avi Kivity wrote:
On 08/10/2011 06:07 PM, Shribman, Aidan wrote:
XBZRLE will very rarely (if at all) degrade live-migration as it runs
at ~2 GB/s or 16 Gbps. Additionally XBZRLE could get even faster by
using 128bit registers instead of the 64bit registers used currently.
On 08/10/2011 06:07 PM, Shribman, Aidan wrote:
XBZRLE will very rarely (if at all) degrade live-migration as it runs at ~2
GB/s or 16 Gbps. Additionally XBZRLE could get even faster by using 128bit
registers instead of the 64bit registers used currently. IMO XBZRLE could
safely be used by defa
-Original Message-
From: Anthony Liguori [mailto:anth...@codemonkey.ws]
Sent: Monday, August 08, 2011 7:56 PM
To: Avi Kivity
Cc: Blue Swirl; Stefan Hajnoczi; Shribman, Aidan; qemu-devel Developers
Subject: Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large
memory apps
On 08/08/2011 11:53 AM, Avi Kivity wrote:
On 08/08/2011 07:19 PM, Anthony Liguori wrote:
Real feature negotiation will likely have to wait until the next version
of the migration protocol.
Since we're talking about moving to ASN.1 for 1.0, I think we should
think also include memory compress
On 08/08/2011 07:19 PM, Anthony Liguori wrote:
Real feature negotiation will likely have to wait until the next version
of the migration protocol.
Since we're talking about moving to ASN.1 for 1.0, I think we should
think also include memory compression and wait until we rev the
protocol be
On 08/08/2011 10:15 AM, Avi Kivity wrote:
On 08/08/2011 06:10 PM, Anthony Liguori wrote:
On 08/08/2011 09:47 AM, Avi Kivity wrote:
On 08/08/2011 05:46 PM, Avi Kivity wrote:
Please provide documentation in docs/ of the compression format.
IMO it should be disabled by default (with an option t
On 08/08/2011 06:10 PM, Anthony Liguori wrote:
On 08/08/2011 09:47 AM, Avi Kivity wrote:
On 08/08/2011 05:46 PM, Avi Kivity wrote:
Please provide documentation in docs/ of the compression format.
IMO it should be disabled by default (with an option to disable it,
via, sat, migrate-set-options
On 08/08/2011 09:47 AM, Avi Kivity wrote:
On 08/08/2011 05:46 PM, Avi Kivity wrote:
Please provide documentation in docs/ of the compression format.
IMO it should be disabled by default (with an option to disable it,
via, sat, migrate-set-options, so we can migrate to older hosts).
The protoc
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
On 08/08/2011 05:56 PM, Stefan Hajnoczi wrote:
> IOW, this should be part of the standard migration protocol, not some side
> option that is enabled if the user remembers. It should not be mutually
> exclusive with future migration extensions, including compression.
This is an attractive opt
On Mon, Aug 8, 2011 at 3:47 PM, Avi Kivity wrote:
> On 08/08/2011 05:46 PM, Avi Kivity wrote:
>>
>> Please provide documentation in docs/ of the compression format.
>>
>> IMO it should be disabled by default (with an option to disable it, via,
>> sat, migrate-set-options, so we can migrate to olde
On 08/08/2011 05:46 PM, Avi Kivity wrote:
Please provide documentation in docs/ of the compression format.
IMO it should be disabled by default (with an option to disable it,
via, sat, migrate-set-options, so we can migrate to older hosts).
The protocol should allow XBZRLE to turn itself off
On 08/08/2011 11: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 downtime
and total live-migration time of VMs running memory write intensive workloa
On 08/08/2011 05:33 PM, Anthony Liguori wrote:
If we have a shared object helper, the thread should be maintained by
qemu proper, not the plugin.
I wouldn't call it "migration transport", but instead a
compression/decompression plugin.
I don't think it merits a plugin at all though. There's lim
On 08/08/2011 09:23 AM, Avi Kivity wrote:
On 08/08/2011 05:15 PM, Anthony Liguori wrote:
If we did .so plugins, which I'm really not opposed to, I'd want the
interface to be something like:
typedef struct MigrationTransportClass
{
ssize_t (*writev)(MigrationTransport *obj,
struct iovec *iov,
i
On 08/08/2011 05:15 PM, Anthony Liguori wrote:
I think workload aware migration compression is possible for a lot of
different types of workloads. That makes me a bit wary of QEMU growing
quite a lot of compression mechanisms.
It makes me think that this logic may really belong at a higher le
On 08/08/2011 08:51 AM, Avi Kivity wrote:
On 08/08/2011 04:29 PM, Anthony Liguori wrote:
One thing that strikes me about this algorithm is that it's very good
for a particular type of workload--shockingly good really.
Poking bytes at random places in memory is fairly generic. If you have a
lo
On 08/08/2011 04:29 PM, Anthony Liguori wrote:
One thing that strikes me about this algorithm is that it's very good
for a particular type of workload--shockingly good really.
Poking bytes at random places in memory is fairly generic. If you have
a lot of small objects, and modify a subset
On 08/08/2011 04:41 PM, Alexander Graf wrote:
In general, I believe it's a good idea to keep looking at libvirt as a vm
management layer and only a vm management layer.
Very much yes.
--
error compiling committee.c: too many arguments to function
On 08/08/2011 08:41 AM, Alexander Graf wrote:
On 08.08.2011, at 15:29, Anthony Liguori wrote:
One thing that strikes me about this algorithm is that it's very good for a
particular type of workload--shockingly good really.
I think workload aware migration compression is possible for a lot of
On 08.08.2011, at 15:29, 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
>> downtime
>> and to
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 downtime
and total live-migration time of VMs running memory write intensive workloa
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 downtime
and total live-migration time of VMs running memory write intensive workloads
typical of large enterprise applications such
31 matches
Mail list logo
