"lxc.lxcpath" and custom storage backend location

Inside /etc/lxc/lxc.conf I specify lxc.bdev.zfs.root = somepool/lxc.

To my understanding, leaving lxc.lxcpath unspecified (by omission), will have LXC create /var/lib/container/{config, rootfs} and mount the ZFS dataset to rootfs.

Is this a sensible approach to take (looks good to me), or would one usually specify a custom lxc.lxcpath in such a case?

Is that LXC or LXD? I do not have that configuration file.

It’s LXC, here is the reference.

I am not familiar with plain LXC, but I might be able to help with your question.

If you do not specify details for a ZFS storage backend, then LXC/LXD would not autocreate a ZFS pool.
ZFS is not the default storage backend. The default storage backend is dir (or Directory), see http://lxd.readthedocs.io/en/stable-2.0/storage-backends/ Here, the container files are just stored on the host’s filesystem, at some default location under /var/lib/

You mention in the title custom storage backend which would be something about a new filesystem used to store the container files. It could be adjusted to something like custom storage backend location.

I have an existing pool somepool/lxc and given the correct path in lxc.conf, the lxc-create command does create a nested ZFS dataset for each new container, so all is well. My question was just whether lxc.lxcpath is usually left alone in such a case, or whether I should point it to some non-default path.

The documentation you posted reads:

ZFS doesn’t have to (and shouldn’t be) mounted on /var/lib/lxd

I wonder if this applies to LXC as well. As I said in my original post, it seems fine to me to have:

/var/lib/container/
│
├── config    # container config file (located here)
└── rootfs/   # mounted ZFS pool (located elsewhere)

But if that’s not recommended, I’d like more experienced users to chime in.

p.s I have updated the title, you’re right.

Slightly related is there any option in the future (or current that I have missed looking through the documentation)to create ZFS datasets with more than one img point or partition (RAIDZ mirror) so as that you have some redundancy in your your mounted ZFS pool. The only way I see would be snapshot the pool then zfs send/receive your snapshot elsewhere?

If not, whats the current best practice to alleviate single point of failure in the zfs datasets/pools?

Thanks

In LXC, the expectation is that you already have an existing ZPOOL setup with LXC then storing containers onto it. How you’ve configured that zpool isn’t important and it can have any device setup you want.

In LXD, LXD can create zpools for you in which case they have a single backing device, either the disk you provided or a loop device. But you can also point LXD at an existing ZPOOl or dataset inside a ZPOOL. Allowing for much more complex zpool setups. All you need to do then is pre-create the zpool with the device configuration that you want, then tell LXD to use it.

Thanks Stephane for the heads up, much appreicated!