Can't create new container on ZFS, when image was deleted

Hi,

I’m using LXD 3.0.3 on Ubuntu 16.04 with ZFS backend.

I have encountered a strange behavior with ZFS and its clones!

Example:
I have created a container with 16.04 image. The image will be downloaded and cloned for the container.
The container has then the image volume as origin:

zfs get all diskpool/lxd/containers/xxx | grep origin
diskpool/lxd/containers/xxx origin diskpool/lxd/images/be4aa8e56eab681fac6553b48ce19d7f34833accc2c8ae65f140a603b8369a1d@readonly -

Now the problem:
It looks like, the image was deleted, while all containers with the origin of the image were stopped.
→ The image was renamed and is now in deleted folder:

diskpool/lxd/deleted/images/be4aa8e56eab681fac6553b48ce19d7f34833accc2c8ae65f140a603b8369a1d@readonly

The origin of the stopped containers is now changed to reflect the new image path…

When I now start a container, it will start without any issues, but it is now impossible to create a new container, because LXD now want’s to move the image back to the not “deleted” path.
This is not possible anymore, because the running containers use the “deleted” path and the volume cannot be umounted.

I think, the best way of resolving this issue, is to deny to delete an image, which is already in use by a container…

BR Florian

This is effectively a ZFS bug which we’ve reported upstream quite a while back and we have a new workaround for this particular case which should make it to 3.0.4.

An ugly workaround for now would be to stop all containers which are based on that image, this should then let zfs rename it back when launching a new one, then all the stopped containers can be started back up again.

Hi Stéphane,

thank you very much! Yes indeed, I used this “ugly” workaround.

Nice to hear, that there is a better workaround in new version!

BR Florian