LXD – The Docker alternative

War of Succession

Article from Issue 176/2015

Several container alternatives to Docker are hoping to extend their claims as virtualization solutions, including Canonical's LXD, which was designed with a view to OpenStack.

Container virtualization for Linux is by no means new: In addition to the classical Linux containers (LXC) [1], OpenVZ [2] has been around for some years as a pioneer. That said, containers were unable to assert themselves in direct competition with full virtualizers for several reasons (see the "Virtualization Solutions" box). The Docker implementation of Linux containers quickly captured the hearts and minds of admins and developers and has sustained its popularity for more than two years now.

Virtualization Solutions

Xen, KVM, and VMware are very successful products in the hypervisor class. For this reason, many admins think first of one of these products when considering virtualization solutions. Both Xen and KVM are full virtualizers, but both also support paravirtualization using appropriate drivers. In principle, all three solutions emulate a whole machine and thus consume considerable resources. With container virtualization, on the other hand, containers emulate just one filesystem within the host.

Then, along came Docker. Initially, Docker's approach to virtualization was successful for a number of reasons. For starters, Docker virtual machines (VMs) are significantly leaner than KVM or Xen because not every virtual system imitates a complete computer. Moreover, Docker makes many tasks easy: Because a container is a closed construct, it can run on virtually any host that supports containers.

When developers write a program, they can easily pass it on to their customers in the form of a container. Overlay images are used as the basis: The same basic image is supplemented with additional layers containing changes. The Docker system is topped off with different administration tools, with which Docker containers can be easily and comfortably managed in the style of a versioning system à la Git.

Reality has struck home for Docker, however. Manufacturers, admins, and developers have all discovered that Docker is not a panacea. Although containers might be convenient, they cannot be meaningfully maintained in production use. Docker might be the perfect solution for developers because they can quickly cobble together a complete development environment based on prebuilt containers; however, in a production environment, say many admins, a Docker container is pretty much like a black box. Because of the various developer overlays, users have no idea of the container's contents. Also, it is virtually impossible to understand changes on the basis of containers.

Among the alternatives that have been showing up is Rocket, penned by the CoreOS developers. In the future, even Systemd will be able to handle containers. Don't forget LXC, which is experiencing a revival and is under development again.

However, Docker suffers from serious problems in everyday use at the data center, not the least of which is playing nice with OpenStack. As a result, alternatives have been shooting out of the ground, including Canonical's player, LXD [3], which was announced at the OpenStack Summit in Paris, France, last year. The timing and venue were no accident: LXD is designated to become Canonical's mainstay in the container virtualization market for OpenStack and thus open up a line of business that the major manufacturers have neglected for a long time.

How does LXD differ from Docker? How does the solution work, and does it really collaborate that well with OpenStack? Linux Magazine took a close look at the first alpha versions of LXD, and the reviewers were quite impressed by what the Shuttleworth developers have served up.


In LXD, Canonical is seeking to work around some of the problems from which Docker suffers. Docker and OpenStack do not get on very well with each other to a large extent because they are based on different concepts. OpenStack has a central image service from which the hypervisors receive their images when they need to start a new VM, whereas with Docker, each host is itself a small image service: To run a container, it must already exist locally in the image memory of the respective Docker host.

The Docker hypervisor driver of the Nova compute module is designed to unite OpenStack and Docker. The hypervisor simply downloads the image from Glance and stores it locally – where it then exists as a zombie image without a name – before the container starts. However, the situation is not entirely satisfactory. Docker should retrieve the image directly from Glance when starting a VM, operate the container locally, and discard the data when the container is no longer needed.


For a long time after the announcement in Paris, hardly any code existed for LXD. For the OpenStack Conference presentation, the developers had released an initial version of their program, including OpenStack integration for downloading, but you couldn't think of using this version in production. Early in 2015, the developers slowly came up with code that offered an outlook on LXD. It is particularly noteworthy that LXD is closely related to LXC under the hood.

The generic term "container" offers much scope for confusion in the Linux universe. Basically, a container is nothing more than a virtual filesystem that is isolated by means of some Linux kernel features, such as namespaces and process groups, from the main physical system.

No matter which container you use – Docker, LXD, or Rocket – the tools used in the kernel are identical. This shifts the focus primarily onto what additional features the container solutions offer to support their use. With LXD, Canonical has obviously chosen to build on the existing LXC solution.

LXD outsources all tasks for starting and managing containers to LXC. LXD itself is only a framework that offers a RESTful API to the admin in the front end and in the background instructs LXC to start containers in line with the user's requirements. The capabilities of the LXC daemon essentially determine what LXD supports.

Trying LXD

Canonical is maintaining the tradition of allowing interested users a sneak peek at the LXD software. If you have Ubuntu 14.04 at hand, you can take a detailed look at LXD. Ubuntu provides the appropriate packages in its own repository (Figure 1).

Figure 1: Installing LXD is no problem on Ubuntu 14.04.

If you do not have a separate Ubuntu host, you can also test LXD in a VMware or VirtualBox VM. Because LXD is not a full virtualizer, it does not require features such as Intel's virtualization technology for directed I/O (VT-D) or AMD's secure virtual machine (SVM). A normal VM with the latest Ubuntu is enough.

The LXD GitHub repository website [3] reveals that the pace of development is currently so fast that only automatically generated nightly builds are possible. To install these on your own system, you first need to enable the corresponding PPA:

sudo add-apt-repository ppa:ubuntu-lxc/lxd-daily

If the add-apt-repository program is not available, you should install two packages: software-properties-common and python-software-properties. The following commands then install LXD on your system:

apt-get update
apt-get install lxd

If you want to drop your own image into the LXD image memory, you can do so using the lxd-images script (Figure 2), which downloads the requested image from an online store and feeds it to LXD. An example for Debian Wheezy would look like:

scripts/lxd-images import lxc debian wheezy amd \
  64--alias debian --alias debian/wheezy --alias debian/wheezy/amd64
Figure 2: After installing LXD, you can use lxd-images to download an LXD image and install it in LXD.

The lxc launch debian command then finally starts a separate container on the basis of Debian Wheezy (Figure 3).

Figure 3: The reward for all this effort: a working LXC container, which can be controlled via LXD.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More