5d48c5d215
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> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Libvirt API for virtualization
Libvirt provides a portable, long term stable C API for managing the virtualization technologies provided by many operating systems. It includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER Hypervisor.
For some of these hypervisors, it provides a stateful management daemon which runs on the virtualization host allowing access to the API both by non-privileged local users and remote users.
Layered packages provide bindings of the libvirt C API into other languages including Python, Perl, PHP, Go, Java, OCaml, as well as mappings into object systems such as GObject, CIM and SNMP.
Further information about the libvirt project can be found on the website:
License
The libvirt C API is distributed under the terms of GNU Lesser General Public License, version 2.1 (or later). Some parts of the code that are not part of the C library may have the more restrictive GNU General Public License, version 2.0 (or later). See the files COPYING.LESSER and COPYING for full license terms & conditions.
Installation
Instructions on building and installing libvirt can be found on the website:
https://libvirt.org/compiling.html
Contributing
The libvirt project welcomes contributions in many ways. For most components the best way to contribute is to send patches to the primary development mailing list. Further guidance on this can be found on the website:
https://libvirt.org/contribute.html
Contact
The libvirt project has two primary mailing lists:
- users@lists.libvirt.org (for user discussions)
- devel@lists.libvirt.org (for development only)
Further details on contacting the project are available on the website: