Re: [Qemu-devel] [PATCH 03/11] Add XBZRLE documentation

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3588 bytes --]

On 08/05/2012 03:13 AM, Orit Wasserman wrote:
> Signed-off-by: Orit Wasserman <owasserm@redhat.com>
> ---
>  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   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]