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
signature.asc
Description: OpenPGP digital signature
