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.

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.

LXD

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.

Basics

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.