On 08/05/2012 03:13 AM, Orit Wasserman wrote: > Signed-off-by: Orit Wasserman <[email protected]> > --- > docs/xbzrle.txt | 136 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 136 insertions(+), 0 deletions(-) > create mode 100644 docs/xbzrle.txt > > diff --git a/docs/xbzrle.txt b/docs/xbzrle.txt > new file mode 100644 > index 0000000..ce577a9 > --- /dev/null > +++ b/docs/xbzrle.txt > @@ -0,0 +1,136 @@ > +XBZRLE (Xor Based Zero Run Length Encoding) > +=========================================== > + > +Using XBZRLE (Xor Based Zero Run Length Encoding) allows for the reduction > +of VM downtime and the total live-migration time of Virtual machines. > +It is particularly useful for virtual machines running memory write intensive > +workloads that are typical of large enterprise applications such as SAP ERP > +Systems, and generally speaking for any application that uses a sparse memory > +update pattern. > + > +Instead of sending the changed guest memory page this solution will send a > +compressed version of the updates, thus reducing the amount of data sent > during > +live migration. > +In order to be able to calculate the update, the previous memory pages need > to > +be stored on the source. Those pages are stored in a dedicated cache > +(hash table) and are > +accessed by their address.
Line wrapping looks weird here; you may want to rewrap this whole paragraph.
> +Migration Capabilities
> +======================
> +In order to use XBZRLE the destination QEMU version should be able to
> +decode the new format.
> +Adding a new migration capabilities command that will allow external
> management
> +to query for it support.
> +A typical use for the destination
> + {qemu} info migrate_supported_capabilities
> + {qemu} xbzrle, ...
Given my comments on 2/11, this would be:
{qemu} info migrate_capabilities
{qemu} xbzrle off, ...
> +
> +In order to enable capabilities for future live migration,
> +a new command migrate_set_capability is introduced:
> + {qemu} migrate_set_capability xbzrle
Based on my reading of 2/11, this must be:
{qemu} migrate_set_capability xbzrle on
But then you go ahead and repeat this information down below; I wonder
if you can simplify things by merging 'Migration Capabilities' and
'Usage' into one section, with just one example.
> +
> +Usage
> +======
> +
> +1. Activate xbzrle
On both source and destination.
> +2. Set the XBZRLE cache size - the cache size is in MBytes and should be a
> +power of 2. The cache default value is 64MBytes.
On source only.
> +3. start outgoing migration
> +
> +A typical usage scenario:
> +On the incoming QEMU:
> + {qemu} migrate_set_capability xbzrle on
If you are going to merge examples, then showing the initial query of
capabilities prior to setting anything might be nice.
> +On the outgoing QEMU:
> + {qemu} migrate_set_capability xbzrle on
> + {qemu} migrate_set_cache_size 256m
> + {qemu} migrate -d tcp:destination.host:4444
> + {qemu} info migrate
> + ...
> + cache size: 67108864 bytes
> + transferred ram-duplicate: A kbytes
> + transferred ram-normal: B kbytes
> + transferred ram-xbrle: C kbytes
> + overflow ram-xbrle: D pages
> + cache-miss ram-xbrle: E pages
Names such as 'ram-xbrle' do not match the code in the remainder of this
series; make sure this example is accurate.
--
Eric Blake [email protected] +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
