On Thu, Jun 23, 2022 at 15:08:30 +0100, Daniel P. Berrangé wrote:
On Thu, Jun 23, 2022 at 03:58:12PM +0200, Jiri Denemark wrote:
> Resolves:
https://gitlab.com/libvirt/libvirt/-/issues/306
>
> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
> ---
> src/qemu/qemu_migration.c | 21 +++++++++++++++++++++
> src/qemu/qemu_migration.h | 1 +
> src/qemu/qemu_migration_params.c | 6 ++++++
> src/qemu/qemu_migration_params.h | 1 +
> 4 files changed, 29 insertions(+)
>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index 272f1b1b59..02a465f6cb 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -2634,6 +2634,12 @@ qemuMigrationSrcBeginPhase(virQEMUDriver *driver,
> }
> }
>
> + if (flags & VIR_MIGRATE_ZEROCOPY && !(flags &
VIR_MIGRATE_PARALLEL)) {
> + virReportError(VIR_ERR_OPERATION_INVALID, "%s",
> + _("zero-copy is only available for parallel
migration"));
> + return NULL;
> + }
It is also not compatible with compression, or TLS.
Yeah, no zero-copy when you need to transform the data in any way. I
think QEMU provides a reasonable error message already. But since it
mentions "multifd" while our flag is called "parallel", I decided to
explicitly handle this case:
internal error: unable to execute QEMU command
'migrate-set-capabilities': Zero copy only available for
non-compressed non-TLS multifd migration
Do you think I should explicitly check all flags instead?
> diff --git a/src/qemu/qemu_migration_params.c
b/src/qemu/qemu_migration_params.c
> index 4e83d8d8bd..cc66ed8229 100644
> --- a/src/qemu/qemu_migration_params.c
> +++ b/src/qemu/qemu_migration_params.c
> @@ -94,6 +94,7 @@ VIR_ENUM_IMPL(qemuMigrationCapability,
> "multifd",
> "dirty-bitmaps",
> "return-path",
> + "zero-copy-send",
> );
Note the QEMU name was picked in case we later get zero copy
receive, as a separately enabled feature.
The question is whether we need to do the same or if we can have a
single zero copy which would enable the right one depending on the side
of migration...
Jirka