Re: Delaying VM startup until block devices are available

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Fri, Jan 26, 2024 at 2:29 AM Orion Poplawski <orion@xxxxxxxx> 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@dev-mapper-luks\x2dbackup.target
> blockdev@dev-mapper-luks\x2dvm\x2d01\x2ddisk0.target
>

This only works if it is guaranteed that blockdev@xxx.target start job
is already queued when virtqemud.service start is requested. In
practice, systemd-cryptsetup is invoked early, before any "normal"
service so it appears to work. But to be on safe side you probably
need

Wants=systemd-cryptsetup@backup.service

or whatever service is used to decrypt device

> 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.
>

Create a systemd generator that parses VM configuration(s) and adds
those requirements on startup.

> 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.
>

As long as all entries in /etc/crypttab are auto and are not nofali,
they are ordered before /etc/crypttab which itself is ordered before
sysinit.target. So any normal service should start only after all
systemd-cryptsetup@xxx.service have completed. After=blockdev@... is
more relevant for shutdown, to ensure applications requiring this
block device will be shut down before systemd-cryptsetup@.service.

I do not know how clevis hooks into all of this. Does it use
systemd-cryptsetup@.service at all?