On Fri, Apr 19, 2024 at 16:29:47 +0200, Peter Krempa wrote:
While QEMU accepts and interprets an empty string in the tls-hostname field in migration parametes as if it's unset, the same does not apply for the 'tls-hostname' field when 'blockdev-add'-ing a NBD backend for non-shared storage migration.
When libvirt sets up migation with TLS in 'qemuMigrationParamsEnableTLS' the QEMU_MIGRATION_PARAM_TLS_HOSTNAME migration parameter will be set to empty string in case when the 'hostname' argument is passed as NULL.
Later on when setting up the NBD connections for non-shared storage migration 'qemuMigrationParamsGetTLSHostname', which fetches the value of the aforementioned TLS parameter.
This bug was mostly latent until recently as libvirt used MIGRATION_DEST_CONNECT_HOST mode in most cases which required the hostname to be passed, thus the parameter was set properly.
This changed with 8d693d79c40 for post-copy migration, where libvirt now instructs qemu to connect and thus passes NULL hostname to qemuMigrationParamsEnableTLS, which in turn causes libvirt to try to add NBD connection with empty string as tls-hostname resulting in:
error: internal error: unable to execute QEMU command 'blockdev-add': Certificate does not match the hostname
To address this modify 'qemuMigrationParamsGetTLSHostname' to undo the weird semantics the migration code uses to handle TLS hostname and make it return NULL if the hostname is an empty string.
Fixes: e8fa09d66bc Resolves: https://issues.redhat.com/browse/RHEL-32880 Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- src/qemu/qemu_migration_params.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>