Change:
lxd supports multiple storage backends, but most of them are unusable. your user to the group (or perform the rest of the steps as root). to initialize a storage backend (e.g using ) that isn't marked on the list below. Nix's lxd storage backend support matrix: [x] Directory (see note 1) [x] Btrfs (see note 1) [x] Zfs (missing path) [ ] LVM Thin Volumes (missing path) [ ] Raw LVM (untested, but seems to not be present in ) [ ] Ceph (untested, but seems to not be present in ) Note 1: LXD does somewhat work with the directory and btrfs backends, but any and all created containers insist that must exist. It doesn't actually get used. This is almost certainly a bug, and is mentioned in . LVM2 and thin-provisioning tools should almost definitely be enabled unconditionally, as per the . Zfs and Btrfs support may potentially be autodetected based on . Ceph is sufficiently uncommon that it may be an explicitly-enabled option. Alternatively, we can have something ala under, say, . I'm going to be busy working for a bit, and am still somewhat unfamiliar with the nix expression language, but I'll take a look at making a (basic, to be expanded upon) patch once I have time.
FWIW, the version of Ceph in nixpkgs is 1) ancient, and 2) marked as broken (due to a DOS vulnerability), so I wouldn't worry about it too much right now. I've been working on packaging a recent (12.2.x) release, but they changed to building using cmake and some outputs are silently not being built by my current expression...
Ceph is the one I'm worried least about (since it's quite uncommon, as far as I can tell). LVM and Zfs, on the other hand, are very common, and currently nonfunctional.
I like supported backends option more than unconditional enabling. This option is not necessarily LXD specific. For instance, current docker module also does not include thin provisioning tools automatically AFAIK.
When it will be completed?
Probably never, I stopped using nix since it ended up not fitting into my workflow very well, with relatively common annoying (to me) side effects (of the immutability bit). If there was work being done it would be availabe in a linked PR ;)
zfsSupport was as a flag in
Ceph module was also revisted in the last release. It also has a test now.
I had this problem with lvm storage backend and was able to work around it by putting the following line to The line above includes lvm tools in the PATH of lxd daemon. Until I did that I was getting the following error from or when trying to create a storage pool:
On the topic of tools which should be included in the lxd module, I think libnvidia-container should be included as well (related issue: ). I really should take a stab at it someday...
I marked this as stale due to inactivity. &rarr;
still not addressed.
I believe is missing as well: But that still fails with " not found" even if I add to the path..
I marked this as stale due to inactivity. &rarr;
For some backends I would add additional options rather than just adding all of them. Qemu for example can be quite big (i.e. pulling in x11 and opengl dependencies).
following the advice of and hitting I found that one should also add to lxd path as such

Discussion:
, attr , bash , btrfs-progs <ins> , cdrkit </ins> , criu , dnsmasq <ins> , e2fsprogs , getent </ins> , gnutar , gptfdisk , gzip , iproute2 , iptables <ins> , kmod , lvm2 , minio , nftables </ins> , OVMF , qemu_kvm , qemu-utils , rsync , spice-gtk , squashfsTools <ins> , thin-provisioning-tools , util-linux </ins> , virtiofsd , xz }:

attr bash btrfs-progs <ins> cdrkit </ins> criu dnsmasq <ins> e2fsprogs getent </ins> gnutar gptfdisk gzip iproute2 iptables <ins> kmod lvm2 minio nftables </ins> qemu_kvm qemu-utils rsync squashfsTools <ins> thin-provisioning-tools util-linux </ins> virtiofsd xz