| 2016-10-05 02:21:57 |
Richard Laager |
description |
Currently, lxd is not explicitly creating the intermediate "containers" and "images" datasets. It is allowing them to be created implicitly by calling "zfs create -p".
I would like to see lxd always (regardless of whether lxd is creating the pool) create these datasets explicitly (e.g. in lxd/main.go) and set "canmount=off" or "mountpoint=none" on both. Otherwise, regardless of which existing dataset I choose, I end up with "/something/containers" and "/something/images" mounted for no reason. Setting "canmount=off" or "mountpoint=none" are the normal approaches for ZFS datasets that only exist to contain other datasets; which one to use depends on whether the children need to inherit a mountpoint. Currently, the children of "containers" and "images" do not need to inherit a mountpoint, as lxd always sets a mountpoint. (This is because lxd wants the mountpoints to be "foo.zfs" rather than just "foo".) So either option would be fine.
I think it would be wise to also set "exec=on" and "setuid=on" on the "containers" dataset. If the children of the "containers" dataset are mounted with noexec ("exec=off"), the container fails to start, for obvious reasons. Likewise, "setuid=on" is necessary for proper operation of setuid executables inside the container. If lxd doesn't set these options itself, it is at the mercy of whatever options might be inherited. This was a problem for me; see below.
Since "devices=off" is not a problem, I don't see any other options to be concerned with. The other options are either irrelevant, or might be something the admin actually wants to control. It's just these two that break the container.
Setting the options as described above would fix the following scenario, plus many other scenarios:
# Simulate a root pool setup that matches the upstream ZFS root HOWTO (which I maintain):
truncate -s 10G /var/lib/rpool.img
zfs create rpool /var/lib/rpool.img
zfs set -o devices=off rpool
zfs create -o canmount=off -o setuid=off -o exec=off rpool/var
# Try to use lxd, following the same dataset convention:
zfs create -o canmount=off rpool/var/lib
zfs create rpool/var/lib/lxd
apt install lxd
lxd init
# Specify "no" to creating a pool, and "rpool/var/lib/lxd" as the existing dataset.
# Accept the rest of the defaults.
lxd launch ubuntu:
The "containers" and "images" datasets are created too late, after data has already been written to /var/lib/lxd/containers and /var/lib/lxd/images. Creating them earlier solves this, as would setting "canmount=off" or "mountpoint=none" regardless of when they are created. The latter has the advantage of also fixing the unnecessary mounting for other cases. |
lxd should ensure that, when using an existing pool, its datasets are not spuriously mounted.
--- Original Description:
Currently, lxd is not explicitly creating the intermediate "containers" and "images" datasets. It is allowing them to be created implicitly by calling "zfs create -p".
I would like to see lxd always (regardless of whether lxd is creating the pool) create these datasets explicitly (e.g. in lxd/main.go) and set "canmount=off" or "mountpoint=none" on both. Otherwise, regardless of which existing dataset I choose, I end up with "/something/containers" and "/something/images" mounted for no reason. Setting "canmount=off" or "mountpoint=none" are the normal approaches for ZFS datasets that only exist to contain other datasets; which one to use depends on whether the children need to inherit a mountpoint. Currently, the children of "containers" and "images" do not need to inherit a mountpoint, as lxd always sets a mountpoint. (This is because lxd wants the mountpoints to be "foo.zfs" rather than just "foo".) So either option would be fine.
I think it would be wise to also set "exec=on" and "setuid=on" on the "containers" dataset. If the children of the "containers" dataset are mounted with noexec ("exec=off"), the container fails to start, for obvious reasons. Likewise, "setuid=on" is necessary for proper operation of setuid executables inside the container. If lxd doesn't set these options itself, it is at the mercy of whatever options might be inherited. This was a problem for me; see below.
Since "devices=off" is not a problem, I don't see any other options to be concerned with. The other options are either irrelevant, or might be something the admin actually wants to control. It's just these two that break the container.
Setting the options as described above would fix the following scenario, plus many other scenarios:
# Simulate a root pool setup that matches the upstream ZFS root HOWTO (which I maintain):
truncate -s 10G /var/lib/rpool.img
zfs create rpool /var/lib/rpool.img
zfs set -o devices=off rpool
zfs create -o canmount=off -o setuid=off -o exec=off rpool/var
# Try to use lxd, following the same dataset convention:
zfs create -o canmount=off rpool/var/lib
zfs create rpool/var/lib/lxd
apt install lxd
lxd init
# Specify "no" to creating a pool, and "rpool/var/lib/lxd" as the existing dataset.
# Accept the rest of the defaults.
lxd launch ubuntu:
The "containers" and "images" datasets are created too late, after data has already been written to /var/lib/lxd/containers and /var/lib/lxd/images. Creating them earlier solves this, as would setting "canmount=off" or "mountpoint=none" regardless of when they are created. The latter has the advantage of also fixing the unnecessary mounting for other cases. |
|
