Re: [Qemu-devel] [PATCH 9/9] block-migration: add named dirty bitmaps migration

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]

On 01/08/2015 03:36 PM, Paolo Bonzini wrote:
> 
> 
> On 11/12/2014 15:17, Vladimir Sementsov-Ogievskiy wrote:
>> Just migrate parts of dirty bitmaps, corresponding to the block being
>> migrated. Also, skip block migration if it is disabled (blk parameter
>> of migrate command is false).
>>
>> Skipping shared sectors: bitmaps are migrated independently of this,
>> just send blk without block data.
> 
> I think dirty bitmaps should be migrated separately from the block
> migration.  It makes a lot of sense to migrate them even if you are not
> using block migration.
> 
> Compared to new flags, the availability of migration capabilities can be
> queried via query-migrate-capabilities before actually invoking the
> migration.  So they are preferred, and you should add a migration
> capability instead of a new argument.

Good point - we still don't have argument introspection (only command
introspection), so turning on bitmap migration with a capability is
indeed preferable over having to probe whether attempting an optional
parameter will induce failure.

> 
> The bitmaps are transmitted many times in their entirety, but only the
> last copy actually means something.  The others are lost.  This means
> you should use the non-live interface (register_savevm).  This will
> simplify the code a lot.

If I understand correctly, you are saying that:

block migration vs. assuming shared storage during migration

is independent from:

current behavior of resetting dirty tracking on destination vs. new
one-shot non-live dirty bitmap migration

and that all four combinations are potentially useful.  Also, by doing
dirty bitmap migration as one-shot at the tail end of migration (in the
small window when things are no longer live) you have a lot less effort,
although the window of non-live activity is now a bit longer if the
dirty table migration is not efficient.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]