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.
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?
>
> 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
>
Regards,
Arun Menon
