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 <pkre...@redhat.com> > --- > src/qemu/qemu_migration_params.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-)
Reviewed-by: Jiri Denemark <jdene...@redhat.com> _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-le...@lists.libvirt.org
