On Mon, Mar 30, 2026 at 09:22:39AM +0100, Daniel P. Berrangé wrote: > On Sun, Mar 29, 2026 at 03:12:25PM -0500, Andrea Bolognani via Devel 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: > > Every systemd dep has a reverse which you can put in the "other" unit > file. > > IOW, in virt-secret-init-encryption.service we need > > RequiredBy: libvirtd.service > > which I think would give us the semantics we need, and (hopefully) > is ignored when libvirtd.service is not present.
That part is not really problematic, we could just use Want= instead of Requires=. It's the credential loading part that trips us up. But see the other sub-thread for a potential solution. -- Andrea Bolognani / Red Hat / Virtualization
