Hi, great video once again. May I ask, why isolated=true is not the default behavior for unprivileged containers? Are there any negative or unpractical consequences of having all your containers as isolated by default?
There are a few reasons, though those are slowly going away and we may at some point be able to set it on by default. The first issue we had with the concept was simply that on some distribution LXD was limited to a total of 100000 uids and gids. This can still be the case on some distributions which make use of /etc/subuid and /etc/subgid. In such environments, LXD would only be able to run a single LXD container before failing. The other category of issues is resource sharing. Passing in a host path or sharing a custom volume between containers is much more difficult (complex ACLs) or effectively impossible. This one is something that our work on shiftfs allowed us to work around and which the upstream work on VFS idmap will fully resolve in time. It will most likely be another 1-2 years before we can reasonably assume solid VFS idmap support on most filesystems, at which point, having to deal with any kind of filesystem remapping will be a thing of the past, simplifying all of this greatly. So anyway, if you are on a system which does not restrict the number of uid/gid used by LXD and you have either: - A recent kernel (5.15 or higher) and aren't using ZFS - shiftfs enabled - No need for shared custom volumes or shifted disk mounts from the host Then setting isolated=true in your default profile is perfectly fine and very likely to be a good idea. That's what I do on my production clusters, where I'm in the first situation as I run LXD with ceph+ext4 which is VFS idmap compatible. My development systems which use ZFS however are currently not using isolated=true.
@@LXD Thank you. Let me rephrase my question... After watching this video, I was considering enacting isolated=true for all new containers on my small cluster. Is there any reason why I shouldn't do so? Should I watch for any specifics before doing so?
If you have any custom storage volumes which are attached to more than one container, then that would be a reason not to use it, or at least not for the affected instances. The same is true if you're using disk devices to share host paths with containers as the switched to isolated would cause the container side id range to be somewhat random, making it hard to keep track of file ownership on the host. If you're just using individual instances without shared storage, then you should be fine to enable isolated mode for all.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
Thank you! This is great :)
Nice video!!! Thank you!!
Hi, great video once again.
May I ask, why isolated=true is not the default behavior for unprivileged containers? Are there any negative or unpractical consequences of having all your containers as isolated by default?
There are a few reasons, though those are slowly going away and we may at some point be able to set it on by default.
The first issue we had with the concept was simply that on some distribution LXD was limited to a total of 100000 uids and gids. This can still be the case on some distributions which make use of /etc/subuid and /etc/subgid. In such environments, LXD would only be able to run a single LXD container before failing.
The other category of issues is resource sharing. Passing in a host path or sharing a custom volume between containers is much more difficult (complex ACLs) or effectively impossible. This one is something that our work on shiftfs allowed us to work around and which the upstream work on VFS idmap will fully resolve in time.
It will most likely be another 1-2 years before we can reasonably assume solid VFS idmap support on most filesystems, at which point, having to deal with any kind of filesystem remapping will be a thing of the past, simplifying all of this greatly.
So anyway, if you are on a system which does not restrict the number of uid/gid used by LXD and you have either:
- A recent kernel (5.15 or higher) and aren't using ZFS
- shiftfs enabled
- No need for shared custom volumes or shifted disk mounts from the host
Then setting isolated=true in your default profile is perfectly fine and very likely to be a good idea.
That's what I do on my production clusters, where I'm in the first situation as I run LXD with ceph+ext4 which is VFS idmap compatible. My development systems which use ZFS however are currently not using isolated=true.
@@LXD Thank you. Let me rephrase my question...
After watching this video, I was considering enacting isolated=true for all new containers on my small cluster.
Is there any reason why I shouldn't do so? Should I watch for any specifics before doing so?
If you have any custom storage volumes which are attached to more than one container, then that would be a reason not to use it, or at least not for the affected instances.
The same is true if you're using disk devices to share host paths with containers as the switched to isolated would cause the container side id range to be somewhat random, making it hard to keep track of file ownership on the host.
If you're just using individual instances without shared storage, then you should be fine to enable isolated mode for all.
Hello,
May I ask, how can we prevent users included in lxd group from creating privileged containers?