On 27 May 2026, at 3:30 PM, Peter Krempa <pkrempa@redhat.com> wrote:

!-------------------------------------------------------------------|
 CAUTION: External Email

|-------------------------------------------------------------------!

On Wed, May 27, 2026 at 09:17:27 +0000, Abhisek Panda wrote:

For encrypted migration of VMs, QEMU provides the TLS-PSK
authentication apart from TLS certificates. This mechanism relies on
pre-shared keys (a secret key that is known to both sender and receiver
prior to secure communication) for providing secure transfer of data.
We store these keys in a pre-shared key file, where each line contains
a pair of identifier and its corresponding key. During an encrypted
migration, the parties negotiate which unique identifier to utilize,
then parse the key file to extract the key matching the identifier.

Add the "migrate_tls_psk_dir" parameter to qemu.conf to allow users to
define the path containing the pre-shared keys. In case the user does
not define this parameter and attempts to utilize TLS-PSK for
migration, we fallback to the configurable "default_tls_psk_dir"
parameter whose value is set to /etc/pki/qemu-psk by default.
In addition, we get the client identity by parsing the migration URI,
defaulting to 'qemu' if username is undefined.

Example entry format in a PSK file:
qemu:61aa7b2c93d4e8f10c25b6a782e3f4051a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d

Suggested-by: Tejus GK <tejus.gk@nutanix.com>
Signed-off-by: Abhisek Panda <abhisek.panda1@nutanix.com>
---
src/qemu/libvirtd_qemu.aug         |  2 ++
src/qemu/qemu.conf.in              | 19 +++++++++++
src/qemu/qemu_conf.c               | 55 +++++++++++++++++++++++++++++-
src/qemu/qemu_conf.h               |  3 ++
src/qemu/qemu_migration.c          |  2 ++
src/qemu/test_libvirtd_qemu.aug.in |  2 ++
tests/testutilsqemu.c              |  2 ++
7 files changed, 84 insertions(+), 1 deletion(-)

[...]

+# Use of TLS-PSK requires the pre-shared key files to be present.
+# The default is to keep them in /etc/pki/qemu-psk. This directory must contain
+# keys.psk - PSK key information
+#
+# If the directory does not exist, libvirtd will fail to start. If the
+# directory doesn't contain the necessary files, VM migration will fail
+# during TLS handshake if they are configured to use TLS-PSK.
+#
+#default_tls_psk_dir = "/etc/pki/qemu-psk"
+
+

What is the point of having a global directory for the PSK keys?

Since the can be transient, libvirt could simply generate a random key
before the migration, write it to a file (IIUC there's
no way to load it from the monitor via an encrypted secret?) and use
that.

Just for the one migration with absolutely no setup needed from the
user.

That way you could avoid all this setup and make migrations work with
TLS out of the box, and the secret itself would be transported in the
migration cookie.

In this design of creating a symmetric key at the source using the libvirt and sharing it with the destination using

the migration cookie has the following concerns that lead to the use of a global directory for

the PSK keys:

1. Transmitting the key via the migration cookie requires a strictly secure communication

channel between the source and destination libvirt instances. Conversely, utilizing a

global directory for Pre-Shared Keys (PSKs) decouples key management

from the control path, achieving the goal of encrypted migration data transfer without

depending on the security of the libvirt communication channel.

2. In a managed direct migration workflow, an intermediary client brokers the connection between

the source and destination. If the key is embedded within the migration cookie, this client gains

full visibility into the secret, creating a significant attack surface within the system architecture.