Re: [PATCH 11/19] qemu: migration_params: Add infrastructure for 'dirty-bitmaps' migration feature
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(a)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.