On Tue, Jun 16, 2026 at 05:08:30 +0000, Abhisek Panda wrote: [...]
Hi Peter,
I have re-architected the support for enabling the TLS-PSK-based encrypted migration in Libvirt. In this design, Libvirt handles the lifecycle of pre-shared keys, managing their generation, persistent storage, and cleanup. We propose the following changes to Libvirt.
1. Add the following configuration attributes: "migrate_base_psk_dir" and "migrate_psk_length" to qemu.conf. This allows users to define the base directory containing the generated pre-shared keys and the size of the pre-shared key in bytes. Note: The default value of "migrate_base_psk_dir" is set to "/var/run/libvirt/qemu" and "migrate_psk_length" is set to "32".
The 'migrate_base_psk_dir' option seems like an implementation detail and shouldn't IMO exist at all. Libvirt just puts it in the VM's run dir which is not configurable and I don't see a reason for it to be configurable. Setting the key length seems reasonable. IMO it'd make more sense to have 'migrate_tls_psk' boolean option to always enable this similarly to the option we have for forcing normal TLS.
2. Introduce a new migration flag VIR_MIGRATE_TLS_PSK, that enables the use of TLS-PSK-based authentication mechanism for an encrypted migration session. 3. If the VIR_MIGRATE_TLS_PSK flag is set, Libvirt generates a random key of "migrate_psk_length" bytes on the source, and embeds it within a new <migration-key> element inside the migration cookie. Subsequently, it writes this key into a file located at <migrate_base_psk_dir>/<vm_uuid>/keys.psk with the following contents: qemu:<generated_key>. 4. The destination Libvirt reads the key from <migration-key> in the incoming cookie. Subsequently, it writes the key into a file located in <migrate_base_psk_dir>/<vm_uuid>/keys.psk with the same content as in step-3. 5. During the perform stage, Libvirt creates the tls-creds-psk QEMU object with the appropriate attributes for enabling encrypted migration.
Makes sense.
6. Upon migration completion and on all failure/abort paths, Libvirt deletes the <migrate_base_psk_dir>/<vm_uuid> directory, thereby ensuring no key specific information is present on the disk.
IIUC you should be able to delete the file as soon as the qemu TLS object is instantiated because it should have already read in the PSK. Nevertheless it makes sense.
Thinking more about this workflow, a client might also utilise an existing PSK stored as a libvirt secret. So, we decided to bake that support in our patches too.
In case the user wants to use an existing secret for a migration session, we extend the design with a new migration parameter: "VIR_MIGRATE_PARAM_TLS_PSK_SECRET_UUID". In this workflow, a user can initialise the pre-shared key as the secret payload. Libvirt is then provided the secret UUID using the "VIR_MIGRATE_PARAM_TLS_PSK_SECRET_UUID" migration parameter. In this case, Libvirt reads the required PSK via lookup of the secret API and utilizes for encrypting the migration stream, skipping the auto generation step entirely.
Yes that makes sense. Specifically the source libvirt must avoid putting the key in the cookie in this mode and the user is required to instantiate the same secret on the destination.