Re: Delaying VM startup until block devices are available

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 26, 2024 at 1: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

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

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux