[PATCH 11/19] qemu: migration_params: Add infrastructure for 'dirty-bitmaps' migration feature

[Peter Krempa]

On Wed, Feb 17, 2021 at 10:42:13 +0100, Jiri Denemark wrote:
> On Thu, Feb 11, 2021 at 16:37:50 +0100, Peter Krempa wrote:
> > Add the migration capability flag and the propagation of the
> > corresponding mapping configuration. The mapping will be produced from
> > the bitmaps on disk depending on both sides of the migration and the
> > necessity to perform merges.
> > 
> > Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> > ---
> >  src/qemu/qemu_migration_params.c | 24 ++++++++++++++++++++++++
> >  src/qemu/qemu_migration_params.h |  5 +++++
> >  2 files changed, 29 insertions(+)

[...]

> > @@ -1202,6 +1225,7 @@ qemuMigrationParamsReset(virQEMUDriverPtr driver,
> >          goto cleanup;
> > 
> >      qemuMigrationParamsResetTLS(driver, vm, asyncJob, origParams, apiFlags);
> > +    /* We don't reset 'block-bitmap-mapping' as it can't be unset */
> 
> So what happens if migration fails? Will mapping be cleared as a side
> effect of removing the temporary migration bitmaps or will it stay set
> for future migration? Although I guess the next attempt would either set
> the appropriate capability and replace the mapping or not set the
> capability and thus any possibly existing mapping would be ignored in
> case it was not cleared, right?

Any further migration which wants to enable the 'dirty-bitmaps'
migration capability must set it's own mapping. QEMU doesn't have a way
to revert to the default mapping once you set it once.

It's not a problem for us though, we always want to set the mapping
because the default one must be from our side considered always wrong.

We don't guarantee that the node names of storage match on the
destination side of the migration and the default mapping expects that.