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

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

> I'm thinking now that the
> appropriate thing is to add live migration of dirty bitmaps to QEMU
> (regardless of whether they are active or not).
Digging the code around, I've found this:

in mig_save_device_dirty which is actually an iteration of live block 
migration, after sending a sector we need to clear appropriate bit in 
migration dirty bitmap (bmds->dirty_bitmap). But we clear such bits in 
all bitmaps, associated with this device:

bdrv_reset_dirty(bmds->bs, sector, nr_sectors);

which is

void bdrv_reset_dirty(BlockDriverState *bs, int64_t cur_sector, int 
nr_sectors)
{
     BdrvDirtyBitmap *bitmap;
     QLIST_FOREACH(bitmap, &bs->dirty_bitmaps, list) {
         hbitmap_reset(bitmap->bitmap, cur_sector, nr_sectors);
     }
}

I don't know why is it so, but with such approach we cant talk about 
dirty bitmap migration. Actually, all other dirty bitmaps, not related 
to this migration are broken because of this.

It's a mistake or I don't understand the concept of several dirty 
bitmaps per device in qemu. I've thought that they are separate 
entities, which are maintained by qemu. And other subsystems like backup 
or migration can create for itself a bitmap and use it not touching 
other bitmaps.. Am I wrong?

Best regards,
Vladimir

On 21.11.2014 19:55, Stefan Hajnoczi wrote:
> On Fri, Nov 21, 2014 at 01:27:40PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>>> 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.
> It would be possible to drive-mirror the persistent dirty bitmap and
> then flush it like all drives when the guest vCPUs are paused for
> migration.
>
> After thinking more about it though, this approach places more I/O into
> the critical guest downtime phase.  In other words, slow disk I/O could
> lead to long guest downtimes while QEMU tries to write out the dirty
> bitmap.
>
>> 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?
> bs->dirty_bitmaps is not migrated, in fact none of BlockDriverState is
> migrated.
>
> QEMU only migrates emulated device state (e.g. the hardware registers
> and associated state).  It does not emulate host state that the guest
> cannot see like the dirty bitmap.
>
>> 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..
> Active dirty bitmaps should migrate too.  I'm thinking now that the
> appropriate thing is to add live migration of dirty bitmaps to QEMU
> (regardless of whether they are active or not).
>
> Stefan