lxc-destroy allows unsafe destruction of overlayfs sources
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lxc (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
The gist of this bug is that 'lxc-destroy -n foo' should at least complain and require some sort of '--force' flag to remove 'foo' if there are containers that are using it for a source of their overlayfs clones.
Example:
## using daily ppa
$ sudo lxc-create -n source-
--release=
$ sudo lxc-create -n source-
--release=
ubuntu-
wget is /usr/bin/wget
Extracting container rootfs
Container source-
$ sudo lxc-clone -o source-
Created container my-clone as snapshot of source-
$ sudo lxc-destroy -n source-
$ echo $?
0
$ sudo lxc-start -n my-clone
lxc-start: No such file or directory - overlayfs: error mounting /var/lib/
lxc-start: No such file or directory - failed to get real path for 'overlayfs:
lxc-start: failed to mount rootfs
lxc-start: failed to setup rootfs for 'my-clone'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'my-clone'
My original lxcapi_clone plan included a 'lxc.snapshots' configuration file entry which would get bumped in the original container by lxcapi_clone, and dec'd by lxc-destroy. However, overlayfs is the only backing store that needs this, and doing this unilaterally would be wrong since in the btrfs case the original doesn't need to stick around.
So let me think a bit more if there's any more elegant solution, and please anyone chime in if you have one. Otherwise I'll probably go with lxc.snapshots after all, and just bump it at lxc-clone -B overlayfs -s.