Is it safe for a VM service to implicitly depend on a directory shared by Incus?

Incus
, ,
1

Incus provides a very convenient way to share a host directory with a VM:

incus config device add VM hostdir disk source=/path/to/host/dir path=/path/to/guest/dir

I assume that this is handled by incus-agent mounting the host share using some virtio/qemu protocol.

Something I’m wondering is if incus-agent will mount this directory early enough in the boot process to make it safe for other services to rely on it.

For example, imagine a have a systemd service that will read its configuration from a/config directory, and I use incus “device add” to mount a host directory in the guest’s /config. Is there some way to ensure that the service will only start after /config is mounted, preventing some race condition where it will see /config unmounted (thus empty) and initialize with the wrong configuration?

2

As far as I can tell is that Incus will mount all the devices before the container services are started.

It is a very common approach for OCI containers to provide configurations or even data storage by adding devices and it just works.

3

As far as I can tell is that Incus will mount all the devices before the container services are started.

I’m sure that for containers it is fine. For VMs, this is the responsibility of incus-agent, which from the VM OS POV, is just another service.

4

incus-agent runs about as early as we can possibly do as it needs to also re-shuffle network configs. So for most units it should be fine, basically any unit that already is waiting for networking should then get its mount.

But if you have extremely early boot stuff, then that may be a problem.

1 Like