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

There's a new version of Canonical's LXD too, but its community fork seems to be thriving

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 slipped your memory, we explained the relationship between LXC and Canonical's LXD back when the Ubuntu vendor pulled out of the Linux Containers project and took LXD in-house, on US Independence Day last year.

Incus is the less Ubuntu-integrated fork of LXD, under the guidance of original lead LXD developer Stéphane Graber. The project is developing fast – as we described last October when Incus 0.1 was released, the developers were busily removing dependencies on internal Canonical tech such as MaaS, Candid and Canonical RBAC. The Incus devs also removed Shiftfs, as its functionality is replaced by ID-mapped mounts in kernel 6.2 and above.

LXC 6.0 is the latest bi-annual update to the Linux Containers tool. This release simplifies LXC somewhat, and drops support for Canonical's old Upstart init system. There's now an option to build it as a single multi-call binary, to which all the various lxc-XYZ subcommands can be symlinked. This can save a lot of disk space – which is especially important for embedded deployments. It can also be statically linked – and to facilitate that, it switches to using libdbus-1 to talk to D-Bus, rather than using libsystemd. This version also enables IPv6 support by default.

Incus 6 is the first LTS version of the relatively new tool. The previous release was Incus 0.7 – the large jump in version numbers aligns Incus with LXC, as well as indicating that this is a stable, long-term release. There's also a corresponding version 6 of LXCFS, and an optional FUSE filesystem launched back in 2015, which filters the visibility of some of the contents of /proc in order to make containers look more like full VMs.

Version 6 widens Incus's storage support. Graber told The Reg:

On the Incus side, we [introduced] a new shared storage driver based on LVM. That's our clustered LVM driver. It allows using any shared drive, whether it's coming from a FiberChannel SAN, an iSCSI volume from a NAS, a fancy NVMEoF device or whatever else. So long as the same disk can be seen by all servers in the cluster concurrently, we can feed that to LVM, set up locking and have a shared storage layer allowing for automatic recovery if a server dies as well as instant live-migration of virtual machines to other machines as all data is accessible on all servers.

Youtube Video

News from upstream

Within Canonical, LXD itself is alive and well. In mid-March, Canonical announced its latest LTS release, LXD version 5.21. We feel that the version numbering is confusing here, but in fairness, this change is Canonical's choice. LXD 5.21 is the fifth LTS release of LXD. As the announcement explained:

Starting with this release we are changing the numbering scheme. This is the first LTS release that won't use the n.0.n format, e.g. 6.0.x, and instead it will be 5.21.x.

What we have followed so far is that each LTS would start a new major version (e.g. 5.0) and each monthly feature release would build on that major version (e.g. 5.1 … 5.20). However, that seemed strange from the perspective of the LTS being an accumulation of all the work that has gone into the monthly releases over the past two years. This is why we decided to change the naming scheme to better reflect that the LTS represents the end of the cycle, rather than the beginning.

The two projects seem to be pulling in different directions. While Incus is opening up its storage support, the new version of LXD doubles down on its storage integration, linking to Dell's PowerFlex hyperconverged infrastructure storage offering – as Reg sister site Blocks and Files explained. LXD 5.21 also removes some of the obsoleted integration functionality that LXD removed some time ago.

This is not necessarily a bad thing – differentiation is good. Former LXD and now Incus supremo Graber attributes this to Canonical changing LXD's license to AGPLv3 and now requiring a Canonical CLA. ®

More about

More about

More about


Send us news

Other stories you might like