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

[Vladimir Sementsov-Ogievskiy]

> 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.
Hm. I'm afraid, it still will not be free. If bitmap is active, it's 
actual version is in memory. To migrate bitmap file like a disk image, 
we should start syncing it with every write to corresponding disk, 
doubling number of io.

Moreover, we have normal dirty bitmaps, which have no name/file, do we 
migrate them? If, for example, the migration occurs when backup in 
progress? Active bitmaps should be migrated in the same way for 
persistent/named/normal bitmaps. I can't find in qemu source, is there 
bitmap migration?

Or you are saying about migrating disabled bitmaps? Hm. We should sync 
bitmap file on bitmap_disable. Disabled persistent bitmap is just a 
static file ~30mb, we can easily migrate it without common procedure 
with cow or something like this..

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