Re: [Qemu-devel] qcow2 autoloading bitmaps

[Eric Blake <eblake@redhat.com>]

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

On 01/11/2018 08:26 AM, Vladimir Sementsov-Ogievskiy wrote:

> # @autoload: the bitmap will be automatically loaded when the image it
> is stored
> #            in is opened. This flag may only be specified for persistent
> #            bitmaps. Default is false for block-dirty-bitmap-add.
> (Since: 2.10)
> 
> so, if we consider only enabled bitmaps it is ok to direct map autoload
> <=> auto.
> 
> But now we've faced into necessity of load/store disabled bitmaps.
> 
> Current behavior is definitely wrong: user sets autoload flag for
> disabled bitmap, but on next
> Qemu start the bitmap will be autoloaded and enabled.

Can we make it an error to set autoload to true when requesting a
disabled bitmap? Or can we not even request a disabled bitmap?

> 
> 
> Proposed solution:
>  - deprecate @autoload flag for bitmap creation, ignore it

Is there ever a case where you'd create an enabled persistent
dirty-tracking bitmap, but not want it to be re-enabled the next time
the image is created?  Your argument for ignoring/deleting the parameter
is that you can decide whether to set the "auto" flag solely based on
whether the bitmap is both persistent and enabled, without needing any
additional user input?

>  - save persistent enabled bitmaps with "auto" flag
>  - save persistent disabled bitmaps without "auto" flag
>  - on Qemu start load all bitmaps, mapping "auto" flag state to
> "enabled" state.

So if I follow the argument, the state of the 'auto' flag stored into
the file on BDS close (often at qemu exit) is based on whether the
bitmap was currently enabled, and the user can then control whether to
enable/disable the bitmap on the fly to control whether the 'auto' flag
is stored; thus, having the flag at creation time is redundant.

> 
> 
> Note: we may store a lot of disabled bitmaps in qcow2 image, but loading
> them all into RAM may be
> inefficient. Actually such bitmap will be needed only on demand (for
> export through nbd or
> making some kind of backup). So in future it may be optimized by "lazy
> load" of disabled bitmaps,
> postponing their actual load up to first read or enabling. This
> optimization doesn't need changing
> of qapi or qcow2 format (at first sight).
> 
> 
> Note2: now there is no way to disable/enable bitmaps, but there is a
>   [PATCH for-2.12 0/4] qmp dirty bitmap API
> with big conversation, but I hope, I'll post a new version with a small
> fix soon and it will be merged.

In other words, you can incorporate your QAPI tweaks proposed here into
your respin of that series.

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


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