<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 26, 2024 at 1:29 AM Orion Poplawski <<a href="mailto:orion@nwra.com">orion@nwra.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We have various VMs that are back by luks encrypted LVs.  At boot the volumes<br>
are decrypted by clevis.  The problem we are seeing at the moment is that the<br>
VMs are started before the block devices are decrypted.  Our current solution is:<br>
<br>
# cat /etc/systemd/system/virtqemud.service.d/override.conf<br>
[Unit]<br>
After=blockdev@dev-mapper-luks\x2dbackup.target<br>
blockdev@dev-mapper-luks\x2dvm\x2d01\x2ddisk0.target<br>
<br>
Where we list each of the volumes to be decyrpted as blocking the virtqemud<br>
service. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Does anyone have any better alternatives?  My main issue it that it feels<br>
somewhere in between fine-grained and coarse-grained control.<br>
<br>
Ideally I think one would be able to have each individual VM startup<br>
automatically delayed until the devices each used became available, but I<br>
don't see how to do this.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Alternatively it seems like one should be able to delay all VM startup until<br>
all volumes in /etc/crypttab were unlocked, rather than having to specify each<br>
one.  But I don't see a target for that.<br></blockquote><div><br></div><div>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...)<br></div><div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>