When using MAAS with LXD Pods, it is currently not possible to configure over-commit of storage. There is a configuration UI to over-commit both Memory and CPU but not Storage. This is required to usefully make use of both thin-provisioned storage (found with LVM Thinpools and ZFS) and storage which optimises space usage (such as ZFS compression).
I have found when using juju to deploy large models with auto-created LXD Pods, initial model creation works and (incorrectly) over-commits storage. From some quick testing, it seems I can continue to allocate new machines until the original large set of machines finish deploying and switch to the Deployed state. Once the machines show as deployed, additional machine allocations fail due to the storage being in the negative. However the storage allocations on the “KVM->LXD” page immediately show the storage as overcommited with a negative free space as soon as they are created (and before they finish deploying). So beware that when testing this, you need to wait until the storage is all used by a Deployed node before you’ll get a failure. I guess that is a separate bug I should also file.
Use case:
I am using juju against MAAS with LXD Pods for my home lab development environment, which I use to test customer scenarios as part of Canonical’s Support Team. I need to squeeze resources a little, and often create 20+ machines (to deploy openstack environments for charm testing).
I need to give a bigger root disk by default but they are rarely fully used - so with thin provisioned storage I never run out of space in practice. I sometimes also will have 2 environments deployed and powerdown one and power-up the other.
I am using an LVM Thin Provisioned storage pool - so the over-commit works fine. That’s also a desired option when using ZFS (which both thin provisions the volumes and also allows much more space usage due to compression) and Ceph - likely among other storage providers.
Originally reported at Bug #2044067 “Pods: unable to overcommit storage” : Bugs : MAAS