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
pgpuYj8ZiRiN_.pgp
Description: PGP signature
