back to article Virtually and actually, LXC 6 and Incus 6 are here – both LTS versions

The community fork of what is now Canonical's in-house virtualization tool seems to be doing well, with major new releases of Incus, LXC and associated tools. The Linux Containers team has announced availability of long-term-support releases of both the Incus 6.0 "containervisor" and the underlying LXC 6.0. In case it's …

  1. ldo

    Linux Containers Can Be Quite Confusing

    Remember that there is no such thing as a “container” primitive as defined by the Linux kernel. Instead, userland-visible kernel objects are grouped into “namespaces” of various kinds, and these, together with “cgroups” for grouping processes, are woven together to provide various kinds of higher-level “container” concepts, for example LXC/LXD, systemd-nspawn, Docker and all the rest.

    The nice thing is, choosing between them is not an either/or situation, since they can coexist.

    1. Liam Proven (Written by Reg staff) Silver badge

      Re: Linux Containers Can Be Quite Confusing

      Well, yes. Arguably there should be, but there isn't.

      LXD and Incus are quite clever, though.

      While LXC is/was somewhat aimed at microservices-style app containers (no init: one binary, close on quit), LXD and Incus are aimed at system containers: a whole distro, minus the kernel, with its own init, multiple processes, etc.

      They both add tools so you can dedicate network ports and other PCI hardware to containers and so on. They make containers work more like full Linux VMs, which is how many users actually use containers in production. Pure microservices are harder work and need a clean-sheet approach.

      Since LXD 4, you can essentially tick a box and that instance starts in a true VM rather than on the shared kernel. It's the admin's choice if it's a fully isolated instance with its own kernel, or a container on the same system-wide shared kernel.

      Bringing them together like this is ingenious, IMHO.

      1. ldo

        Re: LXC — no init: one binary, close on quit

        On the contrary, LXC lets you run up full userlands, complete with init process, if you want. The choice is yours. You even have a choice of templates from different distros—for example, on my Debian system, my /usr/share/lxc/templates/ directory contains over two dozen entries, so I can create userlands running Arch, Gentoo, Devuan (!), Ubuntu, Fedora and others.

        Try that on BSD, for example: e.g. running an OpenBSD userland under FreeBSD. Would that work?

        1. Liam Proven (Written by Reg staff) Silver badge

          Re: LXC — no init: one binary, close on quit

          > On the contrary, LXC lets you run up full userlands

          Point missed error.

          The question is not if you _can_. You can do that with Docker. You can do that with almost any container. It is possible. That is a given.

          We know LXC can do it because LXC is the underlying container engine that LXD uses to do it.

          It is not "is it possible?" The question is: how well it does it work and what extra tooling it provides for managing the results?

          With another container system can you dedicate PCI devices on the host to particular containers? Can you migrate the containers between machines?

          1. ldo

            Re: point missed error

            Remember, it was your phrase: “no init: one binary, close on quit”.

      2. Anonymous Coward
        Anonymous Coward

        Re: Linux Containers Can Be Quite Confusing

        > While LXC is/was somewhat aimed at microservices-style app containers (no init: one binary, close on quit), LXD and Incus are aimed at system containers: a whole distro, minus the kernel, with its own init, multiple processes, etc.

        eh? LXC right from the very start was specifically used for system containers (including an init). I think some hosting companies used it for VPS offerings instead of VServer or OpenVZ.

        Docker started by initially using parts of LXC to implement applications containers (and then eventually replaced the LXC tooling with containerd/runc).

  2. Bebu Silver badge
    Linux

    A good example of the separation of mechanism from policy.

    《Remember that there is no such thing as a “container” primitive as defined by the Linux kernel. Instead, userland-visible kernel objects are grouped into “namespaces” of various kinds, and these, together with “cgroups” for grouping processes, are woven together to provide various kinds of higher-level “container” concepts, for example LXC/LXD, systemd-nspawn, Docker and all the rest.》

    The fairly orthogonal facilities of Linux namespaces, cgroups etc provide the a mechanisms from which the policy (container abstraction) is implemented. X11 used to be the goto example but a bit ragged now. :)

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like