Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting our team. We will be in touch shortly.Close

  1. Blog
  2. Article

Miona Aleksic
on 15 March 2024

LXD 5.21.0 LTS is now available


LXD 5.21.0 is now available

The stable release of LXD, the system container and VM manager, is now available. LXD 5.21 is the fifth LTS release for LXD, and will be supported for 5 years, until June 2029. This release significantly steps up LXD’s abilities in comparison to LXD 5.0 LTS, especially when operating in clustered environments. LXD 5.21.0 will be licensed under AGPL-3.0-only, in line with the change we announced last year. The conditions of the license are designed to encourage those looking to modify the software to contribute back to the project and the broader community. We hope you’ll enjoy what’s in store in this release. Before we jump into features, let’s start with some general changes that come with the new LTS.

Change of version numbering scheme

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. 

Going forward, the last of the monthly releases in the two-year LTS cycle will become the next LTS, in this case, 5.21.0. Then, we will restart the cycle with the first monthly release following the new major version number (e.g. 6.x). To avoid unexpected results for people who assumed the next LTS series would be 6.0.x we will not be releasing LXD 6.0, and the next feature release after this one will be LXD 6.1.

LXD UI is now available by default

As we announced, we now have a dedicated team working on the LXD graphical user interface. We are happy to share that the LXD UI is deemed production grade and is now enabled by default in the LXD snap. We will continue to work on ensuring feature parity of the UI with the CLI. 

Keep in mind that the external listener must still be enabled explicitly by setting core.https_address as outlined in the documentation.

What’s new in LXD 5.21.0 LTS?

Over the past two years, we have steadily been enhancing LXD capabilities to become an even more robust and featureful infrastructure tool. In addition to general features, some of the areas we are addressing are aimed at clustered environments, such as when deploying our newly launched MicroCloud solution, which builds on LXD. 

Authentication and authorization revamp 

As part of a push to provide a more industry-standard solution to authentication and authorization in LXD, we’ve added support for OpenID Connect for authentication and additional mechanisms for fine-grained authorization. The combination of these features will allow users to perform secure authentication and fine-grained access control. With the features completed in LXD, this will also be added to the UI in the coming months.

Please note that due to the change in the database, all users who currently authenticate to LXD with OIDC will temporarily lose access to their cluster, and will have to follow these steps to authenticate

More information is available in the documentation about OIDC and fine-grained authorization

As part of this work, the support for Canonical’s Candid RBAC service has been removed as it is in the process of being deprecated. LXD still supports external OIDC and TLS certificates for authentication.

Storage enhancements: Object storage and PowerFlex support

To cover a wider variety of use cases, we are continuously evaluating adding new storage options and enhancing existing ones. In this LTS, we added support for object storage as well as support for Dell PowerFlex as another option for remote storage.

Object storage on Ceph and local storage pools

LXD now has support for object storage.

We’ve achieved this by adding a whole new concept of storage buckets along with a dedicated command (lxc storage bucket) and APIs. This allows LXD users to create new storage buckets, assign them a size limit and then manage access keys to that bucket. The bucket has its own URL with an S3 API.

For Ceph, we are using its rados gateway providing the S3 API.

For other storage drivers, we are using MinIO project, which lets us offer an S3 compatible API directly from a local storage driver. Please note that this requires an externally provided MinIO server binary, by setting the minio.path setting.

Documentation: How to manage storage buckets and keys and Ceph Object storage driver

Dell PowerFlex

There are various enablement activities between Dell and Canonical as a part of our ongoing partnership. The latest of them is adding support for LXD to interface directly with its PowerFlex service in order to allow LXD instances to be run on its platform. This offers an alternate remote storage option for enterprise use cases, where currently supported storage drivers may not be preferred.

Due to its design, PowerFlex is another LXD storage driver offering remote storage capabilities similar to the already existing implementation for Ceph RBD. 

More information can be found in the documentation.

Virtual Machines: Live migration, AMD SEV, non-UEFI support and ISO volumes

Since introducing support for virtual machines 4 years ago we’ve been adding a variety of features to not only ensure feature parity with system containers but also make sure to cover a wide range of our user’s use cases. Some of the highlights for this LTS are support for live migration, non-UEFI VMs and ISO volumes, as well as enabling AMD SEV.

Fast live migration for virtual machines

This release enables a much-improved VM live migration process, eliminating much of the perceivable downtime. Previously, LXD relied on the stateful stop function, which is the ability to write all the running memory and CPU state to disk, then stop the virtual machine, move it to a new system and start it back up again from where it was using the stored state. The improved functionality, on the other hand, allows the source and target servers to communicate right from the start of the migration. This allows for performing any state transfer in the background directly to the target host while the VM is still running, then transferring any remaining disk changes as well as the memory through multiple iterations of the migration logic and finally cutting over to the target system.

Documentation: Live migration for virtual machines

AMD SEV support for virtual machines

LXD now supports AMD SEV for memory encryption of virtual machines.

On compatible systems (AMD EPYC with firmware and kernel support enabled), setting security.sev to true will have the VM get its memory encrypted with a per-VM key handled by the firmware.

Systems supporting AMD SEV-ES can then turn on security.sev.policy.es to also have the CPU state encrypted for extra security.

Lastly, LXD also supports feeding custom session keys. Combined with LXD’s existing vTPM support, this feature can be used to ensure that the firmware is set up with those user provided keys and that the host operator doesn’t have any ability to tamper with the VM.

Documentation: Instance security options

Non-UEFI support in LXD VMs (CSM)

LXD virtual machines have been designed to use a very modern machine definition from the start. This means LXD VMs offer a QEMU Q35 machine type combined with a UEFI firmware (EDK2) and even Secure Boot enabled by default.

While this works great for modern operating systems, it can be a problem when migrating existing physical or virtual machines into LXD as those machines may be using a legacy firmware (BIOS) and not be bootable under UEFI.

This can now be addressed by setting security.csm to true combined with disabling UEFI Secure Boot by setting security.secureboot to false. This switches QEMU to boot via Seabios directly rather than through EDK2.

Documentation: Security CSM

ISO volumes

It is now possible to upload ISO image files as custom storage volumes. These can then be attached to a virtual machine as a bootable CD disk allowing simplified installation of custom operating systems from a “library” of custom ISO volumes.

Documentation: Launch a VM that boots from an ISO

Instance placement scriptlet

The instance placement scriptlet feature was added to enable a better alternative to LXD’s default instance placement algorithms. Instead of the default behavior of placing a new instance on whichever cluster member was hosting the fewest instances, this new feature allows users to make a more deliberate choice. Now, users can provide a Starlark scriptlet that decides which cluster member to deploy the new instance on based on information about the new requested instance as well as a list of candidate cluster members. Importantly, while scriptlets are able to access certain information about the instance and the cluster, they cannot access any local data, hit the network or even perform complex time-consuming actions.

Documentation: Instance placement scriptlet

Cluster auto-healing

A commonly requested feature by those using LXD with Ceph and OVN, it’s now possible to have LXD automatically recover from a cluster member failure by effectively evacuating all instances to other systems.

This can only work with Ceph backed instances which don’t rely on any server-specific device or configuration.

This is controlled by a new cluster.healing_threshold which defines a number of seconds after which a cluster member is considered to be offline and its instances relocated.

Documentation: Automatic cluster evacuation

Shiftfs support has been removed

Following the removal of shiftfs from the Ubuntu kernel (from Mantic onwards) LXD has now also dropped support for shiftfs. The preferred way for container filesystems to have their UID/GID mappings dynamically shifted is with idmapped mounts. In recent kernels this is now supported for ZFS and Cephfs filesystem (in addition to the long standing support for ext4, xfs and btrfs filesystem).

The features outlined above are only the major highlights of this release. You can read the detailed announcement with a complete changelog on our discourse.  

To get started with LXD, follow the get started guide.

Learn more about LXD on the LXD webpage.

Related posts


Miona Aleksic
26 April 2022

LXD 5.0 LTS is now available

Cloud and server Article

The stable release of LXD, the system container and VM manager, is now available. LXD 5.0 is the fourth LTS release for LXD, and will be supported for 5 years, until June 2027. ...


Simon Fels
20 March 2024

Implementing an Android™ based cloud game streaming service with Anbox Cloud

Cloud and server Article

Since the outset, Anbox Cloud was developed with a variety of use cases for running Android at scale. Cloud gaming, more specifically for casual games as found on most user’s mobile devices, is the most prominent one and growing in popularity. Enterprises are challenged to find a solution that can keep up with the increasing ...


Miona Aleksic
5 March 2024

ESXi Alternative: try open source LXD 

Cloud and server Article

LXD is a modern, secure and robust ESXi alternative. With its intuitive CLI and web interface, users can easily get started and deploy and manage their workloads easily and intuitively. ...