On Mon, May 18, 2020 at 20:52:32 +0300, Vladimir Sementsov-Ogievskiy wrote: > [add Nikolay] > > 18.05.2020 19:26, Peter Krempa wrote: > > On Wed, May 13, 2020 at 16:56:10 +0200, Max Reitz wrote:
[...] > > Is there any difference of handling of persistent and non-persistent > > bitmaps? Specifically I'm curious what's the correct approach to do the > > shared storage migration case when the source and destination image is > > the same one. Should we also instruct to migrate the active ones? or are > > they migrated by writing them to the image and reloading them? > > About migration of persistent bitmaps with shared storage: both variants are > possible: > > 1. if you do nothing (i.e. not enable bitmaps migration capability), > persistent bitmaps are stored on inactivation of source Qemu and loaded on > activation of target Qemu > > 2. if you enable bitmap migration capability, then bitmaps are _NOT_ stored, > they migrate through migration channel > > The difference is in downtime: if we have a lot of bitmap data (big disks, > small bitmap granularity, a lot of bitmaps) and/or slow shared storage, then > with [1] downtime will increase, as we'll have to store all bitmaps to the > disk and load them during migration downtime. With [2] bitmaps migrate in > postcopy time, when target is already running, so downtime is not increased. > > So, in general [2] is better, and I think we should always use it, not making > extra difference between shared and non-shared migration. Thanks for the explanation! What about the inactive bitmaps though? Are they treated the same when opened? Should we consider them for migration through the migration stream? > > == > > And in this way, no difference between persistent and non-persistent bitmaps > migration, let's always migrate them by postcopy [and we go this way (I hope > ;) in Virtuozzo] Yeah, that's probably going to be what libvirt does as well. > > > +# @migrate-set-bitmap-node-mapping: > > > > qemu-5.0 deprecated a bunch of migrate-set- specific commands in favor > > of migrate-set-parameters. Is it worth/necessary to add a new command > > here? > > Hmm probably, we should include mapping into MigrateSetParameters structure? IMO yes. I think it also conveniently sidesteps some of the issues that were discussed in the other threads regarding addition/multiple calls etc. The mapping will be set at once and any other invocation sets a new mapping and that's it. Setting nothing will clear the mapping.