On 1 Jun 2026, at 5:02 PM, Abhisek Panda <abhisek.panda1@nutanix.com> wrote:
On 28 May 2026, at 4:42 PM, Peter Krempa <pkrempa@redhat.com> wrote:
!-------------------------------------------------------------------| CAUTION: External Email
|-------------------------------------------------------------------!
On Thu, May 28, 2026 at 09:45:11 +0000, Tejus GK wrote:
2. In a managed direct migration workflow, an intermediary client brokers the connection between the source and destination.
What do you mean by this? How is it brokered? Which part of the conenction?
Do you mean the non-P2P migration mode? (which is the only case where the migration cookie wouldn't go directly from the source libvirtd/virtqemud to the destination libvirt/virtqemud) That one is secured by the connection transport mentioned above.
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.
So IMO this point doesn't make sense either.
Hi Peter, thank you for the response! For the above, we indeed meant it for the non P2P migration mode, So since the 2 libvirts aren’t talking to each other in this case, the client, must inform the destination libvirt on what the PSK is, and in turn for that, the src libvirt must inform the client what the PSK is.
Actually the client library doesn't have to do anything. The PSK would be generated by the source libvirt daemon and put into the migration cookie. The client handling the migration needs to handle the cookie anyways, so that is for free.
The setup would also work out of the box (if both daemons are new enough) which would allow us to actually enable TLS by default.
Obviously the client inbetween would get to see the PSK, but as explained in my previous reply, the client itself needs to have a connection with 'domain:write', 'domain:start' and 'domain:migrate' permission (if you'd be using ACLs) so the on-disk key can't really be protected from such client anyways.
I think all this would have been much easier, if the client controls the lifecycle of the PSK.
As said above I don't think that this is the case. In fact for any user it's the simplest if the PSK handling happens automagically without any setup.
Even outside this scenario, handing over the the PSK lifecycle management to the client provides greater flexibility and control over PSK parameters such as its key size, cryptographic algorithm,
Agreed. We could add config options for these.
and rotation policies,
Rotation policy doesn't make sense as an advantage because you don't ever get better than single-use keys.
which are indeed some aspects that clients may prefer to manage according to their own security requirements, similar to what happens right now in the x509 scenario.
With this argument, for any client who really wants to deal with generating the PSK, it would IMO make more sense to have the PSK as a virSecret and use it for a single VM.
Storing them as keys is IMO inflexible and actually much worse than the x509 setup because you can't invalidate access to a single (e.g. compromised key) without rekeying everything with a completely shared PSK.
Hi Peter,
Thank you for the input. We're working on a revised design based on your recommendations and will share the update soon.
Thanks Abhisek Panda
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". 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. 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. 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. I plan to send the v2 of the patch series along with the support for providing the pre-shared key to Libvirt using the secret UUID later this week. Looking forward to your reviews.