On Thu, Nov 20, 2014 at 01:41:14PM +0300, Vladimir Sementsov-Ogievskiy wrote:
Also, it may be better to make this as qcow2 extension. And bitmap will be
saved in separate qcow2 file, which will contain only the bitmap(s) and no
other data (no disk, no snapshots).
I think you are on to something with the idea of making the persistent
dirty bitmap itself a disk image.
That way drive-mirror and other commands can be used to live migrate the
dirty bitmap along with the guest's disks. This allows both QEMU and
management tools to reuse existing code.
(We may need to allow multiple block jobs per BlockDriverState to make
this work but in theory that can be done.)
There is a constraint if we want to get live migration for free: The
bitmap contents must be accessible with bdrv_read() and
bdrv_get_block_status() to skip zero regions.
Putting the dirty bitmap into its own data structure in qcow2 and not
accessible as a BlockDriverState bdrv_read() means custom code must be
written to migrate the dirty bitmap.
So I suggest putting the bitmap contents into a disk image that can be
accessed as a BlockDriverState with bdrv_read(). The metadata (bitmap
name, granularity, etc) doesn't need to be stored in the image file
because management tools must be aware of it anyway.
The only thing besides the data that really needs to be stored is the
up-to-date flag to decide whether this dirty bitmap was synced cleanly.
A much simpler format would do for that.
Stefan