LXD is a next generation system container manager. The simplest way to define LXD is to say it’s an extension of LXC.
Technically LXD is a REST API that connects to libxlc, the LXC software library. As you know, LXC, short for “Linux containers”, is a solution for virtualizing software at the operating system level within the Linux kernel.
Now you are probably wondering what is the difference between LXD and Docker? Do they offer the same services or different?
Related: What is a Docker Container: An Introductory Guide for Beginners
The biggest difference between Docker and LXD is that with LXD, your container is a whole simulated OS with it’s own init system. For example, you can pick a Debian container, enter it, install your software, create a service file and enable it.
In other words, Docker specializes in deploying apps while LXD specializes in deploying (Linux) Virtual Machines. Therefore, LXD is much more similar to a VM than Docker is.
LXD 4.20 Highlights
First and foremost, LXD now has initial support for live migration of virtual machines. This works by simply using lxc move to move between two separate LXD servers or lxc move --target to move within a cluster. Assuming the VM is running, live migration will be attempted.
The LXD devs was pretty close to that last year when LXD introduced support for Stateful Snapshots, which was technically making it possible for something close to Live Migration.
LXD now supports network peers, as a peer is added on each side of a pair of networks (can be across projects). Once the peer relation is established, OVN (Open Virtual Network) will be configured to directly route from one network to the other with traffic never leaving OVN.
In previous LXD versions routing from one network to another currently exits OVN, hits the uplink network and then re-enters OVN. As you can guess this can be a huge bottleneck. With network peers support added in LXD 4.20 that bottleneck is now completely removed.
With this release, LXD introduces the concept of network zones. Those are effectively DNS zones that are tied to LXD networks and can be used for forward DNS records, reverse IPv4 or reverse IPv6 DNS records.
Among other things, core scheduling for containers, introduces in LXD 4.19, is now extended to virtual machines. When running LXD on a kernel that supports core scheduling, LXD will automatically ensure that all vCPU threads for a particular VM are part of the same core scheduling group.
For more information about all changes in LXD 4.20, you can refer to the official announcement or visit the project’s website.
