Re: [Qemu-devel] [PATCHv3] block-migration: efficiently encode zero blocks

[Eric Blake <eblake@redhat.com>]

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

On 07/15/2013 04:55 AM, Peter Lieven wrote:
> this patch adds an efficient encoding for zero blocks by
> adding a new flag indiciating a block is completly zero.

s/indiciating/indicating/
s/completly/completely/

> 
> additionally bdrv_write_zeros() is used at the destination
> to efficiently write these zeroes.
> 
> v2->v3:

patch revision history belongs outside of the commit message proper...

>  - changed type of flags in blk_send() from int to uint64_t
>  - added migration capability setting to enable sending
>    of zero blocks.
> 
> Signed-off-by: Peter Lieven <pl@kamp.de>
> ---

...here, after the --- separator.

>  block-migration.c             |   29 +++++++++++++++++++++++------
>  include/migration/migration.h |    1 +
>  migration.c                   |    9 +++++++++
>  qapi-schema.json              |    7 ++++++-
>  4 files changed, 39 insertions(+), 7 deletions(-)

> 
> +++ b/qapi-schema.json
> @@ -613,10 +613,15 @@
>  #          Disabled by default. Experimental: may (or may not) be renamed after
>  #          further testing is complete. (since 1.6)
>  #
> +# @zero-blocks: During storage migration encode blocks of zeroes efficiently. This
> +#          essentially saves 1MB of zeroes per block on the wire. Enabling requires
> +#          source and target VM to support this feature. Disabled by default. (since 1.6)

Does this capability have to be explicitly set on the receiving end, or
can it be automatic?  I'd prefer automatic - where only the sending end
has to explicitly turn on the optimization.

Are there any downsides to unconditionally using this when it is
supported on both sides?  With xbzrle, there are workloads where
enabling the feature can actually penalize performance, so libvirt
exposed the choice of using the feature through its API to the end user.
 But if I understand this feature, there are no downsides to using it,
other than generating a migration stream that the destination will not
understand.  Thus, I don't think libvirt public-facing APIs need to
change, and that it is just a matter of implementing this in libvirt
internals that coordinate the start of a migration:

old -> old: feature not present on source, not enabled
old -> new: feature not present on source, not enabled
new -> old: feature present on source, so query destination; feature not
present on destination, so not enabled
new -> new: feature present on source, so query destination; feature
present on destination, so use it

At any rate, the interface looks sane;
Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
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: 621 bytes --]