[systemd-devel] Delaying VM startup until block devices are available
Lennart Poettering
lennart at poettering.net
Fri Jan 26 08:21:12 UTC 2024
On Do, 25.01.24 16:28, 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:
We generally wait for all devices listed in /etc/crypttab, unless you
set noauto or nofail.
>
> # 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.
I am not sure how libvirt works, but if it runs every VM in a systemd
unit, then you could just order the device before that unit, or the
unit after the device.
Really depends on how libvirt splits things up.
> 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.
This is default behaviour. Anything listed in /etc/crypttab is ordered
before cryptsetup.target, which is ordered before sysinit.target,
which is ordered before basic.target, which is ordered before regular services.
Lennart
--
Lennart Poettering, Berlin
More information about the systemd-devel
mailing list