Lxd snap -> incus migration

1

Hi,

Before when installing LXD, I used these commands;

snap set lxd lxcfs.loadavg=true
snap set lxd lvm.external=true
snap set lxd lxcfs.cfs=true
snap set lxd criu.enable=true

I aim to replace the LXD snap approach with an Incus docker approach. GitHub - cmspam/incus-docker: A project to run incus in docker/podman
Are there any of the above snap settings that need an alternative to achieve the same result?

Gr, Justin

2

I can’t really comment on what’s included in the Docker container, but assuming it behaves like normal packages, then criu.enable and lvm.external don’t need an equivalent as there is no snap layer to configure around those.

lxcfs.loadavg and lxcfs.cfs those need options passed to the lxcfs command, especially --enable-loadavg and --enable-cfs, how you do that will vary based on how the package is made.

I actually need to add an option to do that easily in my Debian packages.

3

not needing an lvm.external alternative maybe partly true when you expose /dev and run udev inside the docker image.

But still got the impression the lvm.external option in snap triggers the lvm binaries on the host, preventing any lvm version conflicts. Or am I wrong?

4

It does indeed, which is why I said I can’t really comment on that Docker thing specifically as it may indeed run into some of the same issues as the snap but possibly without good way around the problem. A native package won’t have that issue though.

5

There were 2 issues with lvm and snap

  • lvm version difference between snap hand host
  • lvm cache inconsistency, meaning you had to vgscan on the host to get an actual view.

Maybe the privileged docker setup with /dev mounted and udev running even has an advantage over snap.
Don’t think there is a lvm caching issue, at least not seen it yet.
To overcome the possible lvm version difference, you could decide to call the lvm tools from withing the docker image.