Re: [PATCH 12/13] qemu: Introduce and wire in 'VIR_MIGRATE_PARAM_MIGRATE_DISKS_DETECT_ZEROES'
On Mon, Sep 30, 2024 at 16:53:55 +0200, Pavel Hrdina wrote:
On Mon, Sep 30, 2024 at 03:29:34PM +0200, Peter Krempa wrote:
> The new 'VIR_MIGRATE_PARAM_MIGRATE_DISKS_DETECT_ZEROES' migration
> parameter allows users of migration to pass in a list of disks where
> zero-detection (which avoids transferring the zeroed-blocks) should be
> enabled for the migration connection. This comes at the cost of extra
> CPU cycles needed to check each block if it's all-zero.
>
> This is useful for storage backends where information about the
> allocation state of a block is not available and thus without this the
> image would become fully allocated on the destination.
>
> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
> ---
> include/libvirt/libvirt-domain.h | 13 ++++
> src/qemu/qemu_driver.c | 20 ++++--
> src/qemu/qemu_migration.c | 105 +++++++++++++++++++++++--------
> src/qemu/qemu_migration.h | 4 ++
> 4 files changed, 110 insertions(+), 32 deletions(-)
>
> diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
> index 4266237abe..6d4cc69c5d 100644
> --- a/include/libvirt/libvirt-domain.h
> +++ b/include/libvirt/libvirt-domain.h
> @@ -1240,6 +1240,19 @@ typedef enum {
> */
> # define VIR_MIGRATE_PARAM_MIGRATE_DISKS "migrate_disks"
>
> +/**
> + * VIR_MIGRATE_PARAM_MIGRATE_DISKS_DETECT_ZEROES:
> + *
> + * virDomainMigrate* params multiple field: The multiple values that list
> + * the block devices for which zero detection (to avoid transferring zero blocks)
> + * is to be enabled. This may increase CPU overhead of the migration. At the
> + * moment this is only supported by the QEMU driver but not for the tunnelled
> + * migration.
We should note that it has to be subset of migrate_disks values.
I'd argue that it's logical that this can apply only if the disk is
being migrated.
I also
wonder if we should add a code that will error out if it's not the case,
currently it would be silently ignored.
I'm firmly in the 'no' region. This can be used also if
'migrate_disks'
is not used so we'd have to cross check against the logic if a disk is
even being migrated.
As written above I'm okay declaring that we "did in fact enable
zero-detection for given migration" if the disk was not
migrated as all zeroes were properly 100% absolutely surely always
detected during that migration. Yes I'm being sarcastic. No I'll not add
this pointless checking code. I was borderline thinking not adding the
check whether the disk targets are valid, but that could be easily
extracted&reused.