Canonical's LXD tool, previously maintained in public under the auspices of the Canonical-sponsored Linux Containers project, is being taken in-house.

On US Independence Day, Canonical announced that the LXD project it sponsors is, um, no longer independent. Previously, development of the LXD project had been carried out as part of the wider Linux Containers project. The Ubuntu Discourse has an FAQ post with a little more information, but still not very much.

LXD has been around for quite a while now: The Reg covered its announcement back in 2014, and the inclusion of the first release in Ubuntu 15.10 the following year. LXC is rather older: we first mentioned it as an up-and-coming option in 2011, a couple of years before Docker first launched.

There has been a considerable amount of confusion around the web about this move, perhaps because as a tool, LXD depends upon the underlying LXC functionality; LXD even uses some of the LXC command-line tools. However, they are not the same thing, and just make the situation more confusing, LXC is just one of multiple tools for managing containers on top of the Linux kernel.

By 2016, there were already enough contenders in this space that we were trying to explain some of the differences. Just a year later, the situation was getting still worse, as various lenders started to launch hybrid tools combining some of the features of containers and VMs.

In brief, LXC is a tool for creating and managing containers on Linux hosts. These days, though, it has lots of rivals, partly thanks to broad compatibility enabled by the OCI initiative specifications. Docker is of course one of the most famous, and in its very early days actually used LXC to run its containers. These days, alternative systems include crun (implemented in C), runc (implemented in Go), and systemd-nspawn, which as the name suggests is part of the systemd init system. American bank Capital One, which used to have quite a lot of techies on staff, has a good rundown of the technology.

These days, most of the interest in running containers is in running large fleets of the things, managed by orchestration tools such is the famous Kubernetes. Everyone wants to be the next dot-com billionaire, and to do that you've got to have a very scalable internet presence. One way to achieve that is to break down your server infrastructure into microservices: lots of little "app containers", each holding a single binary and the essential libraries it depends upon. The theory is that by automating the coordination of lots of these, when you go viral, your web presence can scale up extremely quickly, without human intervention - and without paying for a lot of server VMs to be sitting there idle 99 per cent of the time.

This means that the technological spotlight has moved on to tools for managing whole groups of app containers - "pods", in Kubernetes parlance - and to technical issues such as running them without the need for root privileges, and without a single daemon in control of all of them, leading to tools such as Red Hat's Podman.

Less trendy, but more practical for a lot of people, are system containers, which contain an entire Linux distro including its init system - everything except the kernel. System containers may be very long lived, and are used much like virtual machines - except that they all share the same pool of memory and disk. App containers are created and destroyed on demand: you wouldn't bother migrating them from one host server to another, you would just kill them and start new ones.

The story is a bit different if the container, say, contains an email server with 1000 concurrent users. This is the type of job that LXD is aimed at. LXD uses LXC to create and run system containers, which can be administered like virtual machines: you can dedicate hardware to them, migrate them from one host to another, and so on. (Just to muddy the waters, though, LXD has also been able to manage true VMs since version 4.0.) It even has a browser-based GUI for managing instances visually.

As LWN's excellent comparison of LXC and LXD mentions, Canonical is the primary commercial sponsor of both projects. LXD is cross-platform and can be used on multiple distros: it's primarily distributed as a Snap package, but some distros also include natively-packaged versions, such as Alpine, Arch and Gentoo.

LXC is a separate tool which continues to have its own independent existence - even if it's not very fashionable any more. You can use LXC without using LXD, but LXD depends on LXC for some of its functionality. As such, it's very likely that Canonical will continue to sponsor development of LXC, and that both tools will remain available on various distros, not just Ubuntu. ®

https://www.theregister.com//2023/07/07/canonical_takes_lxd_inhouse/