We are evaluating Intel QAT acceleration for QEMU live migration
Hi Team, QEMU uses GnuTLS for TLS migration, while Intel QAT TLS acceleration is available via OpenSSL engine/provider. Is there any supported way to enable QAT acceleration for migration TLS today, or does this require modifying QEMU to use OpenSSL instead of GnuTLS?
On 4/13/26 12:02, Rohit jadhav wrote:
Hi Team,
QEMU uses GnuTLS for TLS migration, while Intel QAT TLS acceleration is available via OpenSSL engine/provider.
Is there any supported way to enable QAT acceleration for migration TLS today, or does this require modifying QEMU to use OpenSSL instead of GnuTLS?
Yeah, QEMU needs to be changed so that it can support openssl. Though, in case of tunneled migration [1] it's actually libvirt that transfers data onto the destination and it too uses gnutls. Michal 1: https://libvirt.org/migration.html#libvirt-tunnelled-transport
On Wed, Apr 15, 2026 at 11:05:18AM +0200, Michal Prívozník via Devel wrote:
On 4/13/26 12:02, Rohit jadhav wrote:
Hi Team,
QEMU uses GnuTLS for TLS migration, while Intel QAT TLS acceleration is available via OpenSSL engine/provider.
Is there any supported way to enable QAT acceleration for migration TLS today, or does this require modifying QEMU to use OpenSSL instead of GnuTLS?
Yeah, QEMU needs to be changed so that it can support openssl. Though, in case of tunneled migration [1] it's actually libvirt that transfers data onto the destination and it too uses gnutls.
Support for OpenSSL will NOT be added to QEMU. GnuTLS is a nicer API to deal with, OpenSSL is not license compatible with QEMU, and we don't want the extra maintainer burden of multiple TLS impls in QEMU. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
participants (3)
-
Daniel P. Berrangé -
Michal Prívozník -
Rohit jadhav