What is LXD? Manage containers with the Linux Container Daemon

LXD, the Linux Container Daemon, is a management tool for Linux operating system containers. It’s developed by Canonical, which also produces Ubuntu. The company continues to develop LXD to this day and guides the direction of the project.

LXD is a sister technology of LXC, Linux Containers. LXC is a container-based virtualisation technology on the operating system level. LXC combines isolated namespaces and the Linux kernel’s ‘cgroups’ to create isolated environments for executing code. Historically, LXC was also the foundation for the popular virtualisation technology Docker.

One of the basic goals behind the development of LXD was to make the management of LXC containers as comfortable as possible, as is typical for virtual machines. However, the container-based approach delivers a higher performance than virtual machines.

Using LXD, Linux operating system containers can be configured and controlled with a pre-defined set of commands. It’s thus well suited for automating container management and is often used in cloud computing and data centres.

• Security: The containers run in isolated namespaces and can only access certain pre-defined resources.
• Scalability: With LXD, you can manage individual containers on your own laptop or thousands of containers in distributed environments.
• Intuitive usability: LXD provides a clear and easy API and a command line client.
• Based on Linux images: LXD works with all Linux images and thus benefits from the large number of existing Linux distributions.
• Sophisticated resource control: Limits are set for CPU, main memory, network use, mass storage, and kernel resources.
• Access to system hardware: If the configuration allows it, containers can access USB devices, GPU, and mass storage media.
• Network management: Network bridges and tunnels can be created via configuration.
• Mass storage management: LXD supports various storage backends, storage pools, and storage volumes.

The main advantage of LXD is that it enables the container-based virtualisation of an entire Linux operating system. It thus brings together the comfort of virtual machines with the performance of containers.

In contrast to most Docker-based use cases, the focus isn’t on virtualising a single application (app virtualisation). Instead, the Linux system image serves as the basis for each LXD container (system virtualisation). This is advantageous for the administrator, as it opens up access to a large amount of freely available Linux distributions and enables the use of a variety of existing tools.

LXD does have one disadvantage compared with other virtualisation technologies: Since all the containers running on a host have access to the same Linux kernel, the LXD daemon is only available with Linux. Furthermore, Linux is the only operating system that can be virtualised as a guest operating system. However, the command line still works on other non-Linux operating systems.

The REST-API of the LXD can be accessed via the network, meaning that containers can be copied or moved between two computers. And what’s more, LXD supports the creation of computer clusters, which bundle the many individual computing units into a virtual super computer.

They key component of LXD is the privileged daemon that runs on the host Linux system. The LXD daemon provides a REST API via a local Linux socket. Through configuration settings, the daemon can also be accessed using the network. Under the hood, LXD uses LXC as a backend via the library liblxc and its go bindings.

Clients interact with the daemon using the REST API. The API defines a language that can be used to create, control, and change containers. The simplest client is the official command line tool. The command line client provides commands for many common operations and accesses the REST API internally.

In what follows, we’ve put together some basic LXD commands for you. Don’t get confused. The name of the LXD commands is lxc, not lxd. You can try the commands yourself without having to install the command line client on your system. Simply use the web-based interface from the linuxcontainers.org project..

LXD can generally be installed on any modern Linux system. It’s used on private computers as well as for cloud computing platforms and distributed data centres. The main goal is to virtualise an entire Linux operating system long term. LXD thus contrasts with Docker, where the focus is more on short-lived containers that hold a single application. In the words of LXD developer Stéphane Graber:

The included command line client is suitable for managing a small number of containers. However, it’s not designed to handle a large number of containers on numerous distributed hosts. For this use case, you should turn to connections on the platforms OpenStack and OpenNebula.

The main parts of LXD are the above-mentioned daemon, the REST API that it provides, and the command line. In the following, we’ll take a look at the main entities that come into use with LXD.

The container is the main abstraction made available by LXD. An LXD container includes the following properties:

• A Linux file system
• Configuration settings such as resource limits, environment variables, security options, etc.
• Mass storage and network devices
• Configuration profile, from which the container inherits settings
• General properties such as container architecture, name and indication whether the container is short lived or long running
• Runtime status such as network throughput, memory use, etc.

As is typical with other virtualisation technologies, snapshots can be created from a container. A snapshot is identical to the underlying container. They’re immutable, meaning that they can’t be changed. They can only be re-named and deleted. A container can be identically restored based on a snapshot.

Even though LXD is a container-based technology, the Linux system image is involved in the creation of containers. Each LXD container is by definition derived from an image.

The images are normally unmodified Linux distributions, as is the case for virtual machines or cloud instances. An image can be identified by its unique SHA256 hash. In order to make things easier for human users, images can be assigned alias names.

Linux images can be drawn from various sources for use with LXD. The following image servers are pre-defined in LXD:

• ubuntu: Provides stable Ubuntu images
• ubuntu-daily: Provides daily builds of Ubuntu images
• images: Provides a variety of images from other Linux distributions and is managed by the community

The images downloaded by the daemon are automatically held in a cache, so that in cases of repeated use they’re available without delay. If it’s not configured otherwise, LXD will check the version of the downloaded images and load new versions if necessary. Similar to the concept of the vagrant box, an existing container can be published as a new image with LXD.

An LXD profile bundles various container configuration settings. A profile can be applied to several containers; furthermore, several profiles can be applied successively to a single container. In the course of this process, defined configuration values may be overwritten. This is how families of containers can easily be created. LXD is available with two existing profiles:

• The default profile is automatically applied to containers if no alternative profile has been established. This profile contains basic configuration settings, such as the eth0 network device of the container.
• The docker profile configures an LXD container that’s meant to hold a Docker container. The profile prompts the LXD container to load necessary kernel modules and set device settings. It also activates the nesting of containers.

LXD is a network daemon, meaning the command line client can communicate with several remote LXD servers and image servers. Several servers can be configured as remotes. That’s how existing containers can be copied and moved between LXD servers; and it’s via remotes that access to the image server is enabled. In addition to the above-mentioned image servers, the command line client also knows the local remote. This facilitates communication with the local LXD daemon using a UNIX socket.

These days there is a wide spectrum of virtualisation technologies that could in theory be used as alternatives to LXD. They differ with regard to various criteria and can divided into two main groups: traditional VM-based virtualisation tools and container-based technologies. LXD is an exception to this grouping, as it’s a hybrid approach that virtualises an entire Linux operating system using containers.

Some virtualisation tools require Linux to be used as the host system; others can run on any operating system. Some only support Linux as a guest system, while others support various systems. Many container-based technologies place the focus primarily on app virtualisation, whereas virtual machines always involve an entire operating system.

Since LXD is based on LXC, it’s possible to use a ‘naked’ LXC installation as an alternative to LXD. However, the experience will likely be less comfortable. Since there’s no daemon without LXD, virtualisation can’t be controlled on the network. And there also won’t be a REST API to serve as a uniform interface.

Among the well-known virtualisation tools, containerd is most comparable to LXD. It also works as a daemon that provides an API. This makes it possible to manage containers on the network, like with LXD. The technology is integrated in Docker and is frequently used.

In general, you should of course choose the right technology based on your specific needs. Here’s an overview of the most frequently used virtualizationvirtualisation technologies.