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

[Stefan Hajnoczi]

On Thu, Jun 11, 2015 at 02:22:35PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 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..

Okay.  The consistency issue is key to dirty bitmaps so it must be
addressed before we merge patches.

Other terms to describe the flag: "in_use" or "outdated"

> >
> >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.

I see.  That is probably fine.

> 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.

Code might be necessary to ensure that:

1. The source host does not store the bitmap after successful live
   migration handover.  (It could overwrite new data with old data!)

2. The destination host does not discard an "in_use" bitmap when it
   opens the qcow2 file before migration handover.

> For non-shared storage, not loaded bitmaps are not migrated at all. Hmm.. is
> it bad? Looks like so.

That's probably okay since loaded bitmaps are migrated.  Non-shared
storage migration only transfers the contents of attached disks, it does
not transfer qcow2 internal snapshots, for example.  So the current
behavior is consistent with qcow2 non-shared storage semantics.

pgpUfTATNGrPV.pgp
Description: PGP signature