Thanks for the reply, that is the thing lxc image list did not match with what I saw, that is why I did the zfs destroy:
lxc image list
±------±------------±-------±------------±-------------±-----±-----±------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
±------±------------±-------±------------±-------------±-----±-----±------------+
shows nothing at the moment:
lxc storage show local
config: {}
description: “”
name: local
driver: zfs
used_by:
Did you try lxc storage volume delete local image/7519c37df49e0ff6dc896d5b93b4871d63829818b1ed1c39fd46962e4dc689e2?
You should be able to delete all of them, even if one was used to create an instance. LXD will just have ZFS keep it around but it should be gone from the database entirely.
Just a quick question, the reason behind this was we troubleshot an issue where /var on the vm running the lxd containers filled up, path /var/snap/lxd/common/lxd/images
This VM is part of an lxd cluster, but the images were outside of the zpool? Where did those images
come from and it occupied 4+GB but on troubleshooting this I also reloaded the lxd daemon and then saw:
I am just trying to understand why the images were in that folder and how we can prevent them from going “local” and route to some zfs mount point or something?
LXD always stores the raw image tarballs or squashfs in /var/snap/lxd/common/lxd/images. Those are always kept around in case they need to be transferred between servers, verified or are exported by the user.
The images then get unpacked into a dataset on first use and that dataset is cloned to make the instances.
You can move that image storage onto a custom volume in your storage pool though by using the storage.images_volume config option. The same applies to instance backups which are stored as tarballs in /var/snap/lxd/common/lxd/backups which can be controlled through storage.backups_volume.