[systemd-devel] Delaying VM startup until block devices are available

[Mantas Mikulėnas]

On Fri, Jan 26, 2024 at 1:29 AM Orion Poplawski <orion at nwra.com> wrote:

> We have various VMs that are back by luks encrypted LVs.  At boot the
> volumes
> are decrypted by clevis.  The problem we are seeing at the moment is that
> the
> VMs are started before the block devices are decrypted.  Our current
> solution is:
>
> # cat /etc/systemd/system/virtqemud.service.d/override.conf
> [Unit]
> After=blockdev at dev-mapper-luks\x2dbackup.target
> blockdev at dev-mapper-luks\x2dvm\x2d01\x2ddisk0.target
>
> Where we list each of the volumes to be decyrpted as blocking the virtqemud
> service.
>

> Does anyone have any better alternatives?  My main issue it that it feels
> somewhere in between fine-grained and coarse-grained control.
>
> Ideally I think one would be able to have each individual VM startup
> automatically delayed until the devices each used became available, but I
> don't see how to do this.
>

You can't really do this with systemd if it's not systemd that does the
startup... The libvirt daemons need to be patched to watch udev events and
wait for the devices they require.


>
> Alternatively it seems like one should be able to delay all VM startup
> until
> all volumes in /etc/crypttab were unlocked, rather than having to specify
> each
> one.  But I don't see a target for that.
>

If this were plain systemd-cryptsetup, you could add a drop-in for
"systemd-cryptsetup at .service" that adds Before=foo.target. I'm not sure if
clevis integrates with that. (Although honestly I don't see much point in
using clevis for data volumes at all – just use it for the rootfs, and
regular keyfiles in /etc/private for everything else...)

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240126/7eedd282/attachment.htm>