Re: [RFC v2] migration: Add migrate-set-bitmap-node-mapping

[Vladimir Sementsov-Ogievskiy]

18.05.2020 21:20, Peter Krempa wrote:
> 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?

Yes, we should migrate them, as even disabled (inactive) bitmap may be diverged 
with its on-disk version: user may disable it after some modifications.

And again, we don't want to save/load them during downtime. Another option 
would be implement a way to flush-and-unload inactive bitmap when it is not 
needed (e.g. prior to migration start), and do not load inactive bitmaps at 
Qemu start, but only later on demand... But this is another story and may have 
own underwater rocks. So, may be we implement such logic one day, but let it be 
separate.

> > ==
> >
> > 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.


--
Best regards,
Vladimir