What is LXD? Manage con­tain­ers with the Linux Container Daemon

LXD, the Linux Container Daemon, is a man­age­ment tool for Linux operating system con­tain­ers. 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 tech­no­logy of LXC, Linux Con­tain­ers. LXC is a container-based vir­tu­al­isa­tion tech­no­logy on the operating system level. LXC combines isolated namespaces and the Linux kernel’s ‘cgroups’ to create isolated en­vir­on­ments for executing code. His­tor­ic­ally, LXC was also the found­a­tion for the popular vir­tu­al­isa­tion tech­no­logy Docker.

One of the basic goals behind the de­vel­op­ment of LXD was to make the man­age­ment of LXC con­tain­ers as com­fort­able as possible, as is typical for virtual machines. However, the container-based approach delivers a higher per­form­ance than virtual machines.

Using LXD, Linux operating system con­tain­ers can be con­figured and con­trolled with a pre-defined set of commands. It’s thus well suited for auto­mat­ing container man­age­ment and is often used in cloud computing and data centres.

• Security: The con­tain­ers run in isolated namespaces and can only access certain pre-defined resources.
• Scalab­il­ity: With LXD, you can manage in­di­vidu­al con­tain­ers on your own laptop or thousands of con­tain­ers in dis­trib­uted en­vir­on­ments.
• 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 dis­tri­bu­tions.
• Soph­ist­ic­ated resource control: Limits are set for CPU, main memory, network use, mass storage, and kernel resources.
• Access to system hardware: If the con­fig­ur­a­tion allows it, con­tain­ers can access USB devices, GPU, and mass storage media.
• Network man­age­ment: Network bridges and tunnels can be created via con­fig­ur­a­tion.
• Mass storage man­age­ment: LXD supports various storage backends, storage pools, and storage volumes.

The main advantage of LXD is that it enables the container-based vir­tu­al­isa­tion of an entire Linux operating system. It thus brings together the comfort of virtual machines with the per­form­ance of con­tain­ers.

In contrast to most Docker-based use cases, the focus isn’t on vir­tu­al­ising a single ap­plic­a­tion (app vir­tu­al­isa­tion). Instead, the Linux system image serves as the basis for each LXD container (system vir­tu­al­isa­tion). This is ad­vant­age­ous for the ad­min­is­trat­or, as it opens up access to a large amount of freely available Linux dis­tri­bu­tions and enables the use of a variety of existing tools.

LXD does have one dis­ad­vant­age compared with other vir­tu­al­isa­tion tech­no­lo­gies: Since all the con­tain­ers running on a host have access to the same Linux kernel, the LXD daemon is only available with Linux. Fur­ther­more, Linux is the only operating system that can be vir­tu­al­ised 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 con­tain­ers can be copied or moved between two computers. And what’s more, LXD supports the creation of computer clusters, which bundle the many in­di­vidu­al computing units into a virtual super computer.

They key component of LXD is the priv­ileged daemon that runs on the host Linux system. The LXD daemon provides a REST API via a local Linux socket. Through con­fig­ur­a­tion 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 con­tain­ers. The simplest client is the official command line tool. The command line client provides commands for many common op­er­a­tions and accesses the REST API in­tern­ally.

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 linux­con­tain­ers.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 dis­trib­uted data centres. The main goal is to vir­tu­al­ise an entire Linux operating system long term. LXD thus contrasts with Docker, where the focus is more on short-lived con­tain­ers that hold a single ap­plic­a­tion. In the words of LXD developer Stéphane Graber:

The included command line client is suitable for managing a small number of con­tain­ers. However, it’s not designed to handle a large number of con­tain­ers on numerous dis­trib­uted hosts. For this use case, you should turn to con­nec­tions on the platforms OpenStack and Open­Neb­ula.

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 ab­strac­tion made available by LXD. An LXD container includes the following prop­er­ties:

• A Linux file system
• Con­fig­ur­a­tion settings such as resource limits, en­vir­on­ment variables, security options, etc.
• Mass storage and network devices
• Con­fig­ur­a­tion profile, from which the container inherits settings
• General prop­er­ties such as container ar­chi­tec­ture, name and in­dic­a­tion whether the container is short lived or long running
• Runtime status such as network through­put, memory use, etc.

As is typical with other vir­tu­al­isa­tion tech­no­lo­gies, snapshots can be created from a container. A snapshot is identical to the un­der­ly­ing container. They’re immutable, meaning that they can’t be changed. They can only be re-named and deleted. A container can be identic­ally restored based on a snapshot.

Even though LXD is a container-based tech­no­logy, the Linux system image is involved in the creation of con­tain­ers. Each LXD container is by defin­i­tion derived from an image.

The images are normally un­mod­i­fied Linux dis­tri­bu­tions, as is the case for virtual machines or cloud instances. An image can be iden­ti­fied 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 dis­tri­bu­tions and is managed by the community

The images down­loaded by the daemon are auto­mat­ic­ally held in a cache, so that in cases of repeated use they’re available without delay. If it’s not con­figured otherwise, LXD will check the version of the down­loaded 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 con­fig­ur­a­tion settings. A profile can be applied to several con­tain­ers; fur­ther­more, several profiles can be applied suc­cess­ively to a single container. In the course of this process, defined con­fig­ur­a­tion values may be over­writ­ten. This is how families of con­tain­ers can easily be created. LXD is available with two existing profiles:

• The default profile is auto­mat­ic­ally applied to con­tain­ers if no al­tern­at­ive profile has been es­tab­lished. This profile contains basic con­fig­ur­a­tion settings, such as the eth0 network device of the container.
• The docker profile con­fig­ures 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 con­tain­ers.

LXD is a network daemon, meaning the command line client can com­mu­nic­ate with several remote LXD servers and image servers. Several servers can be con­figured as remotes. That’s how existing con­tain­ers 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 fa­cil­it­ates com­mu­nic­a­tion with the local LXD daemon using a UNIX socket.

These days there is a wide spectrum of vir­tu­al­isa­tion tech­no­lo­gies that could in theory be used as al­tern­at­ives to LXD. They differ with regard to various criteria and can divided into two main groups: tra­di­tion­al VM-based vir­tu­al­isa­tion tools and container-based tech­no­lo­gies. LXD is an exception to this grouping, as it’s a hybrid approach that vir­tu­al­ises an entire Linux operating system using con­tain­ers.

Some vir­tu­al­isa­tion 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 tech­no­lo­gies place the focus primarily on app vir­tu­al­isa­tion, whereas virtual machines always involve an entire operating system.

Since LXD is based on LXC, it’s possible to use a ‘naked’ LXC in­stall­a­tion as an al­tern­at­ive to LXD. However, the ex­per­i­ence will likely be less com­fort­able. Since there’s no daemon without LXD, vir­tu­al­isa­tion can’t be con­trolled on the network. And there also won’t be a REST API to serve as a uniform interface.

Among the well-known vir­tu­al­isa­tion tools, con­tainerd is most com­par­able to LXD. It also works as a daemon that provides an API. This makes it possible to manage con­tain­ers on the network, like with LXD. The tech­no­logy is in­teg­rated in Docker and is fre­quently used.

In general, you should of course choose the right tech­no­logy based on your specific needs. Here’s an overview of the most fre­quently used vir­tu­al­iz­a­tion­vir­tu­al­isa­tion tech­no­lo­gies.