On Tue, Feb 10, 2026 at 11:26:39PM +0530, Arun Menon via Devel wrote:
This commit sets the foundation for encrypting the libvirt secrets by providing a secure way to pass a secret encryption key to the virtsecretd service.
A random secret key is generated using the new virt-secret-init-encryption service. This key can be consumed by the virtsecretd service.
By using the "Before=" directive in the new virt-secret-init-encryption service and using "Requires=" directive in the virtsecretd service, we make sure that the daemon is run only after we have an encrypted secret key file generated and placed in /var/lib/libvirt/secrets. The virtsecretd service can then read the key from CREDENTIALS_DIRECTORY. [1]
[...]
+++ b/src/remote/libvirtd.service.in @@ -12,6 +12,8 @@ After=libvirtd.socket After=libvirtd-ro.socket After=libvirtd-admin.socket Requires=virtlogd.socket +Requires=virt-secret-init-encryption.service +After=virt-secret-init-encryption.service Wants=virtlockd.socket After=virtlogd.socket After=virtlockd.socket @@ -29,6 +31,8 @@ Conflicts=xendomains.service Type=notify-reload Environment=LIBVIRTD_ARGS="--timeout 120" EnvironmentFile=-@initconfdir@/libvirtd +Environment=SECRETS_ENCRYPTION_KEY=%d/secrets-encryption-key +LoadCredentialEncrypted=secrets-encryption-key:@localstatedir@/lib/libvirt/secrets/secrets-encryption-key
A bit late to the party, sorry. This change breaks the scenario in which the monolithic daemon is in use and the secret driver is not installed. The error messages is quite clear about what's wrong: $ sudo systemctl start libvirtd.service Failed to start libvirtd.service: Unit virt-secret-init-encryption.service not found. I thought I could fix things by weakening the Requires= into a Want=, which would feel appropriate for an optional component, however that doesn't work either: systemd[1]: Starting libvirtd.service - libvirt legacy monolithic daemon... (libvirtd)[20437]: libvirtd.service: Failed to set up credentials: No such file or directory (libvirtd)[20437]: libvirtd.service: Failed at step CREDENTIALS spawning /usr/sbin/libvirtd: No such file or directory systemd[1]: libvirtd.service: Main process exited, code=exited, status=243/CREDENTIALS systemd[1]: libvirtd.service: Failed with result 'exit-code'. Based on my reading of systemd.exec(5), there doesn't seem to be a way to make this conditional. ImportCredential= is supposed to behave gracefully when the credential doesn't exist, but I don't think it suits our needs otherwise. Of course the monolithic daemon could just grow a hard dependency on the secret driver, but I wouldn't consider that to be a very satisfactory outcome. Thoughts from someone more familiar with the topic than I am? :) -- Andrea Bolognani / Red Hat / Virtualization