Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Support per-container and per-image storage backend #1784
lxd reverts back to dir storage if zfs pool isn't available. It isn't available because it is on a encrypted luks device. lxd should fail instead of silently reverting back to
Steps to reproduce
The current behavior, while a bit odd also has its reasons:
So it doesn't seem like something we can really fix for 2.0. In the future we may want to add more logic to LXD wrt storage handling, like keeping track of what backend each individual container and images use, allowing multiple zpools, ... at which point we could re-architecture this code to return a per pool status and so allow starting LXD in degraded mode.
It was extremely surprising to me that I configured the storage to be on zfs in a specific pool and it still allowed me to create containers when the pool wasn't available. Not only do I want the containers to be on the ZFS mount so they get LUKS, the machine is configured such that
I appreciate that trying to make
This: "Support per-container and per-image storage backend" really needs to happen, we just got stung by this limitation while evaluating LXD.
Ideally when setting up a new container we should be able to specify under which pool it should be created.
Please make this happen, it is a current blocker for us on an LXD + CEPH setup where CEPH itself runs inside of LXD containers and provides zpools for further LXD containers.
Thanks for the great work so far