And the command “lxc config show – expanded alextest” shows root being 100GB. When we log into the container and do a “df -h” we do not see any change, the filesystems are all the same size as before.
I assume we now need to expand the filesystem inside the container or create a new filesystem using the free space from the 100GB. How do we do that?
lxc storage list would tell you, lxc storage show default should tell you more about what’s used.
In general, the most flexibility (and least wasted space) you’d get is using ZFS as the container size would then just be a quota rather than a hard allocation. It also does some convenient things like compression and copy on write and because it’s all done in the filesystem, all limits can be changed live with no issue.
LVM as a backend certainly work, a VG is taken by LXD, thinpool is used to give some amount of copy on write and LVs are created for each container using the size property on the root device as the default size for this. Growing requires a restart of the container though and depending on the filesystem used, shrinking may or may not be possible (xfs doesn’t allow it, ext4 and btrfs are fine with it).
At least with version 3.21 there is still an issue with the lvm driver and xfs Filesystem, at least if running on CentOS (7&8) and Fedora (29-31). Don’t know about other distros.
First you have to expand the filesystem using LXD tools as described in the initial message. You get an error message, that the filesystem could not get extended. The usual LXD tools report inaccurate meta data.
Then you have to stop the container and you MUST NOT restart it until you get the problem fixed! Otherwise the container will never start again (at least not using the LXD tools).
To fix the issue mount the container lv anywhere in the file system, expand it using the standard xfs tool und unmount it.
Now you may start the container again and anything is just fine.
With the EXT4 file system anything works fine, no need to fix anything.