[Qemu-devel] qcow2 autoloading bitmaps

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

Hi all!

I've just noted that there is an unfortunate contradiction between qcow2 
spec and qapi.

In qcow2 we have:
1: auto
  The bitmap must reflect all changes of the virtual
  disk by any application that would write to this qcow2
  file (including writes, snapshot switching, etc.). The
  type of this bitmap must be 'dirty tracking bitmap'.


so auto means enabled bitmaps, which must track dirtiness. It's logical 
to auto-load them
on Qemu start and make them enabled dirty bitmaps.

In Qapi we have:

# @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.


Proposed solution:
  - deprecate @autoload flag for bitmap creation, ignore it
  - 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.


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.

-- 
Best regards,
Vladimir