VIRTUALIZATION & CLOUD NEWS · October 19, 2026 · 6–8 minute read
LXD 6.10 LTS Released: New Features for Containers and Virtual Machines
Canonical has released LXD 6.10.0 LTS, the first long-term-support release in the LXD 6 series. It brings image registries with project-level source restrictions, persistent virtual-machine changed-block tracking, storage and networking improvements, security hardening, and a defined support lifecycle.
What is LXD?
LXD is an open-source system container and virtual-machine manager. It provides a common management interface for running full Linux system environments as containers or virtual machines, with APIs and clustering capabilities for larger deployments.
System containers share the host kernel and are generally lighter than virtual machines. LXD virtual machines run their own guest kernel through hardware virtualization. This makes LXD useful for development environments, infrastructure services, lab workloads, and small private-cloud deployments, depending on workload and operational requirements.
LXD 6.10 is the first LTS release in the 6 series
Canonical announced LXD 6.10.0 LTS on October 19, 2026. It consolidates features, storage and networking advancements, disaster-recovery capabilities, security hardening, and bug fixes delivered during the 6 series.
Canonical’s LTS policy provides five years of standard support. LXD 6.10.z is currently listed as supported until June 2031. An Ubuntu Pro subscription can provide additional support beyond the standard period, subject to Canonical’s terms.
Key features and improvements
Image registries
LXD introduces image registries as a unified way to identify image sources for clusters. Administrators can configure projects with restricted.registries to limit which registries tenants may use when downloading images.
Cluster and image-source integration
Registries can use another LXD cluster as an image source through a cluster link, and Simple Streams image servers are supported. Existing client-side image remotes remain supported, although registry-based selection is the preferred direction for image requests.
Persistent VM changed-block tracking
The Snap package now ships qemu-nbd and qemu-storage-daemon binaries to support persistent changed-block tracking. This capability can help backup workflows identify changed virtual-disk blocks rather than treating every backup as a full copy.
Virtual machine support across architectures
virtiofsd is shipped on architectures with VM support, enabling additional non-amd64 architectures except armhf. The release also updates bundled virtualization components and firmware.
Storage and networking stack
The Snap refreshes QEMU, EDK2 firmware, ZFS branches, LXC, LXCFS, and the NVIDIA Container Toolkit. These bundled component updates matter for device access, storage behavior, guest firmware, and container workloads.
Project and tenant controls
Registry restrictions give administrators a clearer way to govern which image sources projects can access. As with any multi-tenant control, validate the policy with representative project and user permissions before rollout.
Image registries and tenant governance
Image registries provide a consistent abstraction for image sources available to a cluster. For administrators running a shared LXD service, the restricted.registries project setting can limit tenants to approved image sources, reducing dependence on ad hoc URLs and protocols.
This is useful when a team wants to centralize base-image sourcing, control which upstream images are available, or use another managed LXD cluster as an image source. Registry policy should be tested with the project permissions and image sources actually used in production.
Changed-block tracking and backup workflows
Persistent changed-block tracking is a notable virtualization-related addition. By tracking which virtual-disk blocks changed, backup software can potentially reduce the amount of data it needs to read or transfer for incremental backups.
The release notes identify the required QEMU NBD and storage-daemon binaries in the Snap package. This should not be interpreted as automatic backup configuration or a guarantee of compatibility with every backup product. Validate the specific workflow, consistency requirements, retention policy, and restore process before relying on it.
Bundled components and platform notes
| Component / area | Release-note detail | Operational relevance |
|---|---|---|
| QEMU | Updated to 10.2.1+ds-1ubuntu3.2 in the Snap package. | Virtual-machine execution and device emulation. |
| EDK2 firmware | Updated to 2025.11-3ubuntu7.2, including Secure Boot and non-Secure Boot variants. | Guest firmware and boot configuration. |
| ZFS | Updated to 2.2.11, 2.3.9, and 2.4.4 across respective branches. | Storage users should review their specific ZFS branch and host configuration. |
| LXC and LXCFS | Updated to 7.0.0 LTS. | System-container runtime and container filesystem integration. |
| NVIDIA Container Toolkit | Updated to v1.20.1, including libnvidia-container. | Relevant to supported GPU/container deployments; verify driver and hardware compatibility. |
| Build requirements | Building from source requires Go 1.27.1 or newer. | Source-build pipelines must update their toolchain. |
Install or upgrade to LXD 6.10 LTS
Canonical lists the stable LTS Snap channel as the standard installation route for Linux:
sudo snap install lxd --channel=6/stableIf LXD is already installed, review the official upgrade guidance and your current Snap channel before changing tracks. For production clusters, plan maintenance, confirm backup and recovery procedures, and test workloads and storage integrations before rollout.
Official release and installation resources:
Read LXD 6.10 release notesOpen LXD documentation
- LXD source releases
- Canonical announcement: MicroCloud and LXD LTS releases
- LXD release tracks and support policy
Should you adopt LXD 6.10?
LXD 6.10 is the natural LTS candidate for teams looking for a supported 6-series baseline. Its registry controls may be particularly useful for multi-tenant environments, while persistent changed-block tracking is worth evaluating for VM backup workflows.
Before moving a production environment, verify your Ubuntu release and kernel compatibility, storage backend, network configuration, remote image sources, backup integrations, and any third-party automation. A long support window reduces lifecycle uncertainty, but does not replace change management or restore testing.
VMoreCloud verdict
LXD 6.10.0 LTS is a significant lifecycle milestone as the first LTS release in the 6 series, with support listed through June 2031. Image registries and project-level restrictions improve governance, while persistent VM changed-block tracking is relevant to backup and recovery designs. The bundled component updates also make compatibility testing important for storage, virtualization, and GPU workloads.
This article summarizes published Canonical release information and does not claim independent testing or benchmark results.
Official sources
- Canonical LXD 6.10.0 release notes
- Canonical LXD and MicroCloud LTS announcement
- Canonical LXD release and support policy
- Canonical LXD source repository
Editorial note: Version, support, and feature details were checked against Canonical’s LXD documentation and release announcement on October 19, 2026. Check the current vendor documentation before planning a production upgrade.
