[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v2] migration: Add migrate-set-bitmap-node-mapping
From: |
Peter Krempa |
Subject: |
Re: [RFC v2] migration: Add migrate-set-bitmap-node-mapping |
Date: |
Mon, 18 May 2020 20:20:56 +0200 |
User-agent: |
Mutt/1.13.4 (2020-02-15) |
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.
- Re: [RFC v2] migration: Add migrate-set-bitmap-node-mapping, (continued)