Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1739557

Summary: RFE: add support for native TLS encryption on migration TCP transport
Product: Red Hat Enterprise Virtualization Manager Reporter: Michal Skrivanek <michal.skrivanek>
Component: vdsmAssignee: Milan Zamazal <mzamazal>
Status: CLOSED ERRATA QA Contact: Beni Pelled <bpelled>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: danken, lleistne, lsurette, mavital, mkalinin, mtessun, mzamazal, rdlugyhe, sgoodman, srevivo, ycui
Target Milestone: ovirt-4.4.0Keywords: FutureFeature
Target Release: 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: vdsm-4.40.13 Doc Type: Enhancement
Doc Text:
With this update, you can enable encryption for live migration of virtual machines between hosts in the same cluster. This provides more protection to data transferred between hosts. You can enable or disable encryption in the Administration Portal, in the Edit Cluster dialog box, under Migration Policy > Additional Properties. Encryption is disabled by default.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-08-04 13:27:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1754533, 1781149    
Bug Blocks:    

Description Michal Skrivanek 2019-08-09 13:56:58 UTC
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

Comment 1 Milan Zamazal 2019-08-13 15:03:55 UTC
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.

Comment 2 Milan Zamazal 2019-09-04 15:42:03 UTC
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.

Comment 3 Dan Kenigsberg 2019-09-28 07:33:35 UTC
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.

Comment 4 Milan Zamazal 2019-09-30 08:12:58 UTC
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.

Comment 12 Beni Pelled 2020-06-30 08:44:02 UTC
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

Comment 16 errata-xmlrpc 2020-08-04 13:27:17 UTC
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