Re: [Qemu-devel] [PATCH v2 RFC 0/8] block: persistent dirty bitmaps

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

On 10.06.2015 18:27, Stefan Hajnoczi wrote:
> On Mon, Jun 08, 2015 at 06:21:18PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> QCow2 header is extended by fields 'nb_dirty_bitmaps' and
>> 'dirty_bitmaps_offset' like with snapshots.
>>
>> Proposed command line syntax is the following:
>>
>> -dirty-bitmap [option1=val1][,option2=val2]...
> Two questions:
>
> 1. How does this code ensure that the dirty bitmap is consistent after
> crash/power failure?

It's not done yet. What about consistent ('dirty' is not very good for 
dirty bitmaps=) flag for every bitmap? Set it on save and unset on load..

>
> At the minimum, enabled dirty bitmaps must be discarded after
> crash/power failure if we cannot guarantee they are up-to-date.  It's
> worse to rely on an outdated dirty bitmap than to detect failure and
> start afresh.
>
> 2. How do persistent dirty bitmaps work with live migration?  Remember
> there are two storage cases for live migration: shared storage (NAS or
> SAN) and non-shared storage (disk images must be copied over).
For now:
Only loaded bitmaps are migrated.
So, for shared image, all is ok: loaded bitmaps are migrated (in 
migration, if there is a bitmap with same name, size and granularity on 
destination, then it will be transparently used as destination bitmap), 
not loaded bitmaps are the same in the image.
For non-shared storage, not loaded bitmaps are not migrated at all. 
Hmm.. is it bad? Looks like so.

I can add a function to load all not loaded bitmaps from the image in 
disabled state. Then variants:
1) call it automatically before migration
2) add a cmd parameter, to load 'all other bitmaps' in disabled state
3) always load all available bitmaps.

(1), (3) are bad I think, because bitmaps may be stored in separate file 
(especially for non-qcow2 images), and, if this file is not mentioned in 
cmd (all bitmap are not loaded), then there is no possibility of 
migrating them automatically.


-- 
Best regards,
Vladimir
* now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.