Hi Andrea, On Mon, Mar 30, 2026 at 04:57:41AM -0400, Andrea Bolognani wrote:
On Mon, Mar 30, 2026 at 03:45:31AM -0500, Andrea Bolognani wrote:
On Mon, Mar 30, 2026 at 12:24:06PM +0530, Arun Menon wrote:
Hi Andrea,
Thank you for finding this.
On Sun, Mar 29, 2026 at 03:12:25PM -0500, Andrea Bolognani wrote:
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.
We can change the Requires= to Wants=, like you mentioned, it will gracefully skip if the encryption service is not found.
Yeah, this part is easy.
Can we move the LoadCredentialEncrypted= and Environment= out of libvirtd.service.in in to a separate file, and then use meson.build to optionally install the new file to the configuration directory systemd/system/libvirtd.service.d/ if conf.has('WITH_SECRETS') is set?
That won't work, because when building distro packages all features get enabled at compile time. The decision about whether the rpm/deb/whatever containing the secret driver gets installed is made later, by the local admin, and is completely out of our control.
We could, however, ship that override snippet as part of the libvirt-daemon-driver-secret package. That seems to work:
$ grep -i secret /usr/lib/systemd/system/libvirtd.service
$ cat /usr/lib/systemd/system/libvirtd.service.d/secret.conf [Unit] Requires=virt-secret-init-encryption.service After=virt-secret-init-encryption.service
[Service] Environment=SECRETS_ENCRYPTION_KEY=%d/secrets-encryption-key LoadCredentialEncrypted=secrets-encryption-key:/var/lib/libvirt/secrets/secrets-encryption-key
$ sudo systemctl start libvirtd Failed to start libvirtd.service: Unit virt-secret-init-encryption.service not found.
Not the most elegant solution perhaps, but I can't come up with anything better. I wonder how many system packages ship systemd unit overrides this way. The mechanism clearly exists though...
I made an attempt to fix this. https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/DDS4C... I tested it by building the configuration files and then manually copying them to the respective unit directories. With -Ddriver_secrets=disabled, libvirtd starts just fine. If -Ddriver_secrets=enabled, the encryption service is called on starting libvirtd. It requires /var/lib/libvirt/secrets folder to be alredy present. Thank you again.
-- Andrea Bolognani / Red Hat / Virtualization
Regards, Arun Menon