Re: [PATCH 2/2] migration: dirty-bitmap: Allow control of bitmap persistence on destination

[Eric Blake <eblake@redhat.com>]

On 2/3/21 7:00 AM, Peter Krempa wrote:
> Bitmap's source persistence is transported over the migration stream and
> the destination mirrors it. In some cases the destination might want to
> persist bitmaps which are not persistent on the source (e.g. the result
> of merge of bitmaps from a number of layers on the source when migrating
> into a squashed image) but currently it would need to create another set
> of persistent bitmaps and merge them.
> 
> This adds 'dest-persistent' optional property to
> 'BitmapMigrationBitmapAlias' which when present overrides the bitmap
> presence state from the source.

persistance

> 
> Signed-off-by: Peter Krempa <pkrempa@redhat.com>
> ---
>  migration/block-dirty-bitmap.c | 30 +++++++++++++++++++++++++++++-
>  qapi/migration.json            |  7 ++++++-
>  2 files changed, 35 insertions(+), 2 deletions(-)
> 

> +++ b/qapi/migration.json
> @@ -533,12 +533,17 @@
>  # @alias: An alias name for migration (for example the bitmap name on
>  #         the opposite site).
>  #
> +# @dest-persistent: If populated set the bitmap will be turned persistent
> +#                   or transient depending on this parameter.

s/populated set/present,/

> +#                   (since 6.0)
> +#
>  # Since: 5.2
>  ##
>  { 'struct': 'BitmapMigrationBitmapAlias',
>    'data': {
>        'name': 'str',
> -      'alias': 'str'
> +      'alias': 'str',
> +      '*dest-persistent': 'bool'
>    } }
> 
>  ##
> 

The grammar fix is trivial, so
Reviewed-by: Eric Blake <eblake@redhat.com>

I see there is discussion over whether this is the best approach, but it
makes sense to me.  Unless there's a good reason why something else
would be better, I'm probably going to queue this through my dirty
bitmaps tree for a pull request sometime next week.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org