Re: [Qemu-devel] [PATCH v2] persistent dirty bitmap: add QDB file spec.

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

> 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.
What tools do you mean? In my opinion dirty bitmap should exist as a 
separate object. If it exists, it should be loaded with it's drive image 
and it should be maintained by qemu (loaded and enabled as a 
BdrvDirtyBitmap). If we use qcow2 format for dirty bitmaps, we can store 
metadata using header extension..

Also snapshots may be used to store several bitmaps in case when server 
shutdowns during backup and we need to store both current active bitmap 
and it's snapshot used by backup.

Best regards,
Vladimir

On 20.11.2014 14:36, Stefan Hajnoczi wrote:
> 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