This bug was initially created as a copy of Bug #1300769 we should actually do this for RHV as well, at least as an option. It shouldn't be hard to add, the TLS stuff should be all set....just toggle a flag. Clone of QEMU bug to track libvirt enablement tasks for native TLS encryption with migration. +++ This bug was initially created as a clone of Bug #1300768 +++ Description of problem: None of the QEMU migration transports have native support for encryption. As such apps/users needing security must tunnel the QEMU migration transport over another channel such as libvirt's secure connection. This is inefficient resulting in many more data copies and lower throughput for migration which reduces chances of it completing. Providing native TLS encryption support for migration in QEMU will allow for secure migration with a lower performance overhead Latest upstream code review posting is: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg01914.html
To implement this functionality we will need (at least): - To add support for TLS encryption option from Engine to VDSM. - To add the option to Engine, in the cluster migration UI. - Point libvirt/QEMU configuration to the right certificates.
There is an issue with certificates: We use destination IP address to initiate migrations, while the host certificates use host names. That means the destination (IP) address doesn't match the certificate and a TLS migration fails. We must ensure that IP addresses are put into the host certificates.
Note that the migration IP of a host can change if a new network is assigned the migration role, or when the migration network is attached to a host with a new static address, or if DHCP server provides a new address instead of renewing the host lease. In these occasions, someone/something should enroll a new certificate to the host.
We've decided to solve the certificate problem by adding an option to libvirt that specifies what to verify in the destination certificate, see bug 1754533. As a temporary workaround until the libvirt feature is implemented, the host name is used in the connection URI when an encrypted migration is requested. This ignores contingent migration network, but we have no better option, since updating the certificates would be too complicated.
Verified with: - ovirt-engine-4.4.1.5-0.17.el8ev.noarch - vdsm-python-4.40.20-1.el8ev.noarch All tests [1] passed except HE migration which is waiting for [2] [1] https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/wiki/Compute/4_4_Migration_Encryption [2] https://bugzilla.redhat.com/show_bug.cgi?id=1850909
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (RHV RHEL Host (ovirt-host) 4.4), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:3246