Watching Lennart's presentation on youtube (the famous one in 2013), Lennart explains that systemd-nspawn is not conceived to be used on production and server environments (as OpenVZ is, at least for us), but only for testing, development, debugging, etc.
Does this limitation of scope still remain? Or has the project "expanded" over the last 10 years in the direction of production environments usage as well?
Does this limitation of scope still remain? Or has the project "expanded" over the last 10 years in the direction of production environments usage as well?
On Thu, Jul 6, 2023 at 5:19 PM Paulo Coghi - Coghi IT <paulocoghi@xxxxxxxxx> wrote:
Obs: when I mentioned the open source manager, what I meant was about my startup doing the development, in case the systemd community is interested.On Thu, Jul 6, 2023 at 5:04 PM Paulo Coghi - Coghi IT <paulocoghi@xxxxxxxxx> wrote:Hello Systemd Devel team,
I've been using OpenVZ for 11 years in production without the security problems I faced with LXC. But as a non-official mainstream library of Linux kernel, there is always a gap. Virtuozzo is working on OpenVZ 9 with kernel 5.14 now, but it is still not released.
Systemd-nspawn seems promising, and I would like to cordially ask a few questions.
1. Does systemd-nspawn officially support system containers?
I would like to not conclude it myself, but it seems so, after reading the official documentation.
2. The "experience" inside a system container is similar to a VM, like on OpenVZ?
On OpenVZ containers, except for kernel related activities (like adding kernel modules), everything is identical to a virtual machine, with the "root" user from the container being able to manage everything, like adding new users, changing firewall rules, installing multiple services (web servers, databases), managing cron jobs, etc.
3. Security - Can those OS containers be used in production, with multiple containers from multiple owners inside the same host?
On LXC, for example, there are vulnerabilities that can be exploited, allowing a container user to escape to the host. On OpenVZ, it seems that his was already addressed more than a decade ago.
Does systemd-nspawn provide such security, not allowing a "container user" to escape to the host?
4. Storage and Inodes
On OpenVZ, we could create "virtualized" file systems, like ploop, which avoids consuming inodes on the host's file system, while lightweight enough to provide near-native performance.
Is there any approach to have similar benefits through systemd-nspawn?
I really hope to use systemd-nspawn as our new system container manager!
Off-topic: If all answers are positive, is there any interest by the systemd team on an MVP of an open source manager for systemd-nspawn, like Proxmox was to OpenVZ/LXC?
Kind regards,
Paulo Coghi
