No, unfortunately you can’t, the image will be kept in your zpool until the last container that was created from it goes away.
That’s because ZFS’ model for dataset cloning keeps a reference to the entire source dataset, not to individual blocks within the dataset (as btrfs does for example). Meaning that even if your container no longer shares a single block with the image it was originally created from, you still cannot destroy that image without also causing your container to get deleted…
When doing a zfs destroy (without -r!),you’ll see which container it blocks. Then I promoted the container dataset (zfs promote ). After that I was able to destroy the deleted image dataset.
Is this procedure wrong? So far it doesn’t seem to harm at least
Hmm, I have bad memories of trying to get zfs promote to help in those cases but I think in the case where you only have a single container tied to a particular deleted image, it may be fine.
If you have more than one container though, then it’d make the other containers depend on the one you promoted without LXD knowing about it, so that’d likely get you into troubles when then trying to delete that first container.
The @readonly snapshot will also get moved from the image to the container which may confuse LXD if you ever try to copy/move your container over the network to another ZFS system (which then uses zfs send/receive and would result in an unknown snapshot that LXD doesn’t know what to do with).
So anyway, zfs promote may be an option if you’re indeed dealing with a single container that was created off that now deleted image and you either find a way to clean any extra snapshots that appear as a result or don’t plan on migrating that container to another system, in other cases, it’d likely cause more harm than good.
How do I check which container is tied to a image?
If I try to do zfs destory I get
# zfs destroy lxd/deleted/images/11fc1b1d39b9f9cd7e9491871f1421ac4278e1d599ecf5d180f2a6e2483bd172
cannot destroy 'lxd/deleted/images/11fc1b1d39b9f9cd7e9491871f1421ac4278e1d599ecf5d180f2a6e2483bd172': filesystem has children
use '-r' to destroy the following datasets:
lxd/deleted/images/11fc1b1d39b9f9cd7e9491871f1421ac4278e1d599ecf5d180f2a6e2483bd172@readonly
Maybe I asking to stupid. Better that then taking down our production server
I think it doesn’t have a container attached to it anymore, but as Stephane noted, better leave it.
About promoting: normaly when creating a container it clones the image dataset, which is not more then just a pointer, so it doesn’t take up extra space. So you can run 1000 containers based on the same image, which uses just de diskspace for the image. When you change a container, the container diskspace usage will start to grow (difference between base cloned image and current state). Create for example a container and look at zfs list what the diskspace usage is (under the column used). It’s almost nothing compared to the base image size. Look now under the number in the column REFER. That will match closely the base image size.
Anyway back to promoting… when you would promote the dataset belonging to the container, then you kind of copy the whole base image into the container dataset, so it matches the complete container. Just promote a containers dataset and look at zfs list for the changes. The used size will be now close to the base imae size too.
Anyway comparing sizes in zfs is a bit more complex then I just tried to explain, but I hope you got an idea now
Try deleting the snapshot first as that’s what’s used by the containers, so zfs destroy lxd/deleted/images/11fc1b1d39b9f9cd7e9491871f1421ac4278e1d599ecf5d180f2a6e2483bd172@readonly should tell you exactly what’s using that image.
I don’t think that ZFS recurses in that warning, so deleting the image itself only warns about the @readonly snapshot rather than show you the snapshot and anything that was based on it.
Ok, so when I run zfs destroy lxd/deleted/images/11fc1b1d39b9f9cd7e9491871f1421ac4278e1d599ecf5d180f2a6e2483bd172@readonly it tells me exacly wich container.
Thanks. This helps a lot. And I learned a lot. I wonder if I export the container, deleted is from the server and then import it again would it recreate the deleted image?
is possible to start a new container from a deleted image?
And if this is the name what do I do next lxd/deleted/images/641797338216a0b974cbf55e377d3b19aef7bcc94859c99233dfe333ef4a0385
It’s not possible to create a container from a delete image as LXD no longer has any of the image metadata.
However if you find a server that does have the image, LXD will re-import it pretty quickly as it won’t have to re-create the zfs data.
Exporting a container and re-importing it will indeed remove the link to its parent image, as would moving the container to another host and back.
I have this same problem, but don’t see that “lxc export” is available to me. I’m running lxd version 3.03, which is later than the version listed in this thread.
Can you elaborate on how I can export/import a container to have it purge the deleted image from ZFS?