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 <p...@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 <ebl...@redhat.com> -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature