The latest release of LXD, Canonical’s system container and virtual machine manager, arrived this month with a batch of features that may not make mainstream headlines but carry significant weight for infrastructure teams running large-scale deployments. LXD 6.7, announced on the project’s GitHub and covered by Phoronix, brings improvements to OVN networking, cluster recovery, storage configuration, and several quality-of-life changes that reflect the software’s continued maturation under Canonical’s stewardship.
For those unfamiliar with the backstory, LXD has had a turbulent few years. Originally developed as an open-source project under the Linux Containers umbrella, it was effectively pulled under Canonical’s direct control in late 2023 when the company moved the project from its community-governed home to a Canonical-managed GitHub repository. That move prompted the creation of Incus, a community fork led by former LXD maintainers. The two projects now develop in parallel, with LXD remaining tied to Canonical’s commercial interests and Incus operating under the Linux Containers project. LXD 6.7 is the latest chapter in Canonical’s effort to demonstrate that the project continues to advance under its sole direction.
OVN Networking Gets Smarter Interconnect Handling
One of the headline features in LXD 6.7 is improved support for OVN (Open Virtual Network) interconnections. OVN, the virtual networking layer that sits atop Open vSwitch, is a critical component for organizations running software-defined networking across distributed clusters. The new release adds the ability to configure OVN interconnect settings directly through LXD, reducing the need for manual out-of-band configuration of the OVN Interconnect Controller (IC) databases.
Specifically, LXD 6.7 introduces new configuration keys — ovn.northbound.ic and ovn.southbound.ic — that allow administrators to point their LXD-managed OVN deployments at interconnect databases. This matters for multi-site or multi-cluster deployments where separate OVN control planes need to exchange routing information. Previously, wiring up OVN IC required touching configuration files and services outside of LXD’s management plane. Bringing this into LXD’s own configuration model simplifies administration and reduces the surface area for misconfiguration. As reported by Phoronix, this is part of a broader push to make LXD a more self-contained management layer for both compute and networking.
Cluster Recovery: Healing Without the Headaches
Cluster management has long been one of LXD’s distinguishing features compared to simpler container runtimes. LXD 6.7 extends this with improvements to cluster recovery and member healing. The release adds a cluster.healing_threshold configuration option that allows administrators to set the amount of time after which an offline cluster member is automatically evacuated. This means workloads on a failed node can be redistributed to healthy members without manual intervention, a feature that production environments with strict uptime requirements will welcome.
The threshold is defined in seconds, and once exceeded, LXD will treat the offline member as permanently gone and begin migrating its instances. This is a meaningful step toward self-healing cluster behavior, though administrators will need to tune the threshold carefully to avoid false positives during transient network partitions or planned maintenance windows. The addition reflects feedback from operators running LXD in environments where manual cluster recovery introduces unacceptable delays.
Storage and Configuration Refinements
Storage handling also received attention in this release. LXD 6.7 adds support for configuring the block size used by LVM (Logical Volume Manager) thin pools through a new lvm.thinpool_block_size setting. While this may seem like a minor knob to expose, it has real implications for workloads with specific I/O patterns. The default block size in LVM thin provisioning is not always optimal for all use cases — database workloads, for instance, may benefit from larger block sizes that reduce metadata overhead, while workloads with many small random writes might prefer smaller blocks. Giving LXD administrators direct control over this parameter removes the need to pre-configure storage pools outside of LXD or resort to workarounds.
Additionally, the release includes improvements to how LXD handles ISO images for virtual machines. The ability to attach and manage ISO files has been refined, making it easier to boot VMs from installation media or attach driver disks during provisioning. This is particularly relevant for users running Windows or other non-Linux guests inside LXD-managed QEMU virtual machines, a use case that Canonical has been quietly expanding support for over the past several releases.
The Incus Shadow: Two Projects, One Lineage
Any discussion of LXD’s development trajectory is incomplete without acknowledging Incus, the fork that emerged from the community’s dissatisfaction with Canonical’s governance changes. Incus, maintained by Aleksa Sarai and other former LXD contributors under the Linux Containers project, has been releasing at a rapid clip and has attracted a segment of the user base that prefers community governance over corporate stewardship. The two projects share a common codebase ancestry but have been diverging in both features and philosophy.
LXD 6.7’s feature set shows that Canonical is not standing still. Some of the improvements in this release — particularly around OVN and cluster healing — address pain points that enterprise users have raised repeatedly. Whether these features were developed independently or in response to Incus’s own development is difficult to determine from the outside, but the competitive dynamic between the two projects appears to be accelerating development on both sides. For infrastructure teams evaluating their options, the choice between LXD and Incus increasingly comes down to whether they prefer Canonical’s integrated support model or the community fork’s independent governance.
Bug Fixes and the Unglamorous Work That Matters
Beyond the headline features, LXD 6.7 includes a substantial list of bug fixes and minor improvements that reflect the kind of ongoing maintenance work that keeps production deployments stable. Fixes to AppArmor profile handling, improvements to the migration subsystem, and corrections to how certain API endpoints handle edge cases are all present in the changelog. These are the kinds of changes that rarely get attention in release announcements but represent the bulk of what makes a container manager trustworthy in production.
The release also updates several internal dependencies and addresses issues reported by users running LXD on newer Linux kernel versions. Keeping pace with kernel development is a persistent challenge for any project that interacts heavily with namespaces, cgroups, and device passthrough — all areas where LXD operates. The project’s CI infrastructure, which tests against multiple kernel versions and distributions, continues to be a significant investment for Canonical’s engineering team.
What This Means for the Broader Container and VM Management Space
LXD occupies an unusual position in the infrastructure software market. It is neither a Kubernetes competitor nor a simple Docker alternative. Instead, it targets a specific niche: organizations that want to manage system containers and virtual machines through a unified API, often as a lightweight alternative to full-blown cloud infrastructure platforms like OpenStack. Canonical has positioned LXD as a building block for its own cloud offerings, including MAAS (Metal as a Service) and Juju, and the project’s development priorities reflect this integration strategy.
The 6.7 release does not represent a dramatic shift in direction. Rather, it is an incremental but substantive improvement to a tool that a meaningful number of organizations depend on for their daily operations. The OVN interconnect support, cluster healing threshold, and LVM thin pool configuration options are the kinds of features that solve specific, well-understood problems — and that is exactly what production users need from a point release.
LXD 6.7 is available now through Canonical’s Snap package distribution channel. Users on the latest/edge channel will have already received the update, while those on the stable channel can expect it following the standard validation period. Full release notes and source code are available on the project’s GitHub repository. For organizations evaluating LXD for new deployments, the 6.x series represents the current long-term development line, with Canonical providing commercial support through Ubuntu Pro subscriptions.
WebProNews is an iEntry Publication