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

[Stefan Hajnoczi]

On Fri, Nov 28, 2014 at 04:28:57PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 21.11.2014 19:55, Stefan Hajnoczi wrote:
> >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).
> I think, we should migrate named dirty bitmaps, which are not used now. So
> if some external mechanism uses the bitmap (for example - backup) - we
> actually can't migrate this process, because we will need to restore the
> whole backup structure including a pointer to the bitmap, which is too hard
> and includes not only bitmap migration.
> So, if named bitmap is enabled, but not used (only bdrv_aligned_pwritev
> writes to it) it can be migrated. For this I see the following solutions:
> 
> 1) Just save all corresponding pieces of named bitmaps with every migrated
> block. The block size is 1mb, so the overhead for migrating additionally a
> bitmap with 64kb granularity would be 2b, and it would be 256b for bitmap
> with 512b granularity. This approach needs additional fields in BlkMigBlock,
> for saving bitmaps pieces.

block-migration.c is not used for all live migration.  So it's important
not to tie dirty bitmap migration to block-migration.c, at least there
needs to be a way to skip actually copying disk contents in
block-migration.c.

(When there is shared storage that both source and destination hosts can
access then block-migration.c is not used.  Also, there is a newer
non-shared storage migration mechanism that is used instead of
block-migration.c which is not tied into the live migration data stream,
so block-migration.c is optional.)

> 2) Add DIRTY flag to migrated block flags, to distinguish blocks, which
> became dirty while migrating. Save all the bitmaps separately, and also
> update them on block_load, when we receive block with DIRTY flag on. Some
> information will be lost, migrated dirty bitmaps may be "more dirty" then
> original ones. This approach needs additional field "bool dirty" in
> BlkMigBlock, and saving this flag in blk_send.
> 
> These solutions don't depend on "persistence" of dirty bitmaps or persistent
> bitmap file format.

That's an important characteristic since we probably want to migrate
named dirty bitmaps, whether they are persistent or not.

Stefan

pgpqkLf5KDDmu.pgp
Description: PGP signature