Lead Image © dixiland, Photocase.com

Lead Image © dixiland, Photocase.com

Established container solutions in Linux

Old Hands

Article from ADMIN 31/2016
Container solutions are not newcomers to the virtualization scene; they have existed for years. We look at the different flavors available for Linux systems.

When talk turns to Linux and container virtualization, the name you nearly always hear is Docker. Docker has managed to plant its name with a certain amount of force in the administrator's field of view and IT strategies. In fact, you might gain the impression that Docker invented container virtualization for Linux systems. However, it has been around for about 15 years and has been in production use for a long time. In this article, I reveal why containers are so attractive to administrators and the fundamental approaches that vie for the administrator's attention.

Containers vs. Full Virtualization

Virtualization comes in different flavors. In one camp are full virtualizers, in the form of virtual computers, that give you a complete system with a virtual BIOS that looks like a physical server to the software running on it. Under normal circumstances, the software on the VM doesn't even notice that it is not running on metal. Today, administrators typically choose this approach. Paravirtualization in particular has helped popularize full virtualization. In paravirtualization, the virtualizer makes better use of the host's hardware, thus resulting in better performance.

Full virtualization has one major disadvantage, however: Because this approach always simulates a complete computer, it also generates more overhead. To put it another way, by running multiple virtual machines (e.g., with KVM and Qemu or Xen) the host wastes resources that would otherwise be available to the virtualized computers.

On a small scale, this effect is not particularly tragic, but the problem scales with the environment. Cloud service providers in particular are affected: The more virtual machines they have running in a setup (and need to manage), the greater the overhead. Therefore, the density of virtual machines per host or rack is limited, which affects the planning of large-scale data centers and explains why administrators are so grateful for container virtualization.

With containers, the host does not emulate a complete computer; it has no virtual BIOS and no kernel. All the containers on the system share the same operating system kernel, access the hardware directly, and are managed by the host kernel. This eliminates almost entirely the overhead caused by full virtualization.

Kernel Dependence

Critics maintain that containers cannot represent genuine virtualization. After all, only the filesystem is virtual in the case of a container. Everything else relies on the host kernel functions to ensure that the various containers do not battle each other for resources and work as desired. In the past, these functions regularly gave rise to heated debate in the kernel developer camp.

Several years ago, OpenVZ, whose commercial variant was later dubbed Virtuozzo, was launched as one of the first container solutions for Linux. At the time, container virtualization was not a big topic for the Linux kernel, which completely lacked the functionality to support it.

OpenVZ overcame this deficiency with its own patched Frankenstein kernel, which was absolutely necessary if you wanted to use OpenVZ containers on the host. Many attempts to integrate the OpenVZ patches into the kernel failed for technical reasons. Finally, parts of OpenVZ became the basis for cgroups and network namespaces, which today provide a framework for containers on Linux. To this day, OpenVZ still needs its own patched kernel if admins want to use the full functionality provided by the software.

The free Linux operating system was pretty much a latecomer in terms of a framework to implement containers in the kernel; in particular, FreeBSD offered its own container implementations at an early stage. (See "The Bigger Picture" for information about containers on other Unix-style operating systems.) LXC was the first solution that offered an option for using containers based on cgroups, which is generally regarded as reliable, and practically all of today's container solutions for Linux are based on cgroups and its various namespaces for networks and processes.

The Bigger Picture

Although Docker and others have made containers usable in a production environment (or at least in the Linux environment), if you ask a FreeBSD or Solaris admin about containers based on the Docker or LXC principle, don't expect much enthusiasm. Other Unix-style operating systems tackled the topic of container functionality in the mainstream kernel far earlier than Linux – and more successfully, in most cases.

FreeBSD Jails

The prime example is jails in FreeBSD (Figure 1). They became part of the package in FreeBSD 4 (2000), prompted by Derrick T. Woolworth, who was looking for a reliable virtualization solution without the typical overhead for his hosting company, R&D Associates Inc.

Under the lead of Poul-Henning Kamp, the BSD developers set off to establish more or less an additional layer for assigning access permissions in FreeBSD – and that is precisely what a jail is: the permission to access certain isolated areas of the operating system. Other jails remain completely untouched. Almost the entire isolation magic occurs at the kernel level; users only ever see the components they are supposed to see.

Jails became part of the FreeBSD system in version 4.0; in other words, they can look back on more than 15 years of existence. But to this day, they are still very popular with FreeBSD admins, and the kernel structures for jails in FreeBSD are regularly updated.

Solaris Zones

The container era started for Solaris more than 10 years ago: Zones were first included in Solaris 10 (2005) and have been renamed "containers" since. They work much like Docker containers in Linux: Various kernel functions isolate a running container from the rest of the system. The container itself only has access to selected and defined resources of the host, and breaking out is virtually impossible. The applications inside the container do not even notice that they are running in a container.


Away from FreeBSD and Solaris, container virtualization does not look quite as rosy on Unix-style operating systems. OpenBSD and NetBSD both relied on sysjails [1] initially, but the project died in 2009. Containers on BSD can only be provided meaningfully with jails in FreeBSD right now.

HP-UX supports containers that offer access restrictions and separate namespaces for files, host and domain names, network addresses, and IPC structures such as semaphores, queues, and shared memory. IBM's AIX offers something related in the form of workload partitions (WPARs), and even Windows is not restricted to Hyper-V containers but now also has a Docker engine.

Figure 1: Jails made their way into FreeBSD as early as version 4.0, and they have proven to be a reliable solution.

From the outset, Docker set out to leverage the kernel's functionality for its containers. Other solutions, such as Linux-VServer still do very much their own thing, which tends to make using them quite complicated.


The prize for the first container-style solution for Linux goes to the Linux-VServer project: As early as 2001, the project went public with kernel patches (Figure 2). At the time, the idea was revolutionary in numerous respects – even full virtualizers like Xen or KVM were miles away from the success that they currently enjoy.

Figure 2: To this day, the Linux-VServer patch reconstructs the Linux kernel, which is a disadvantage: No administrator enjoys the prospect of running a Frankenstein kernel.

For most users at the time, a server was simply metal that lived in a server cabinet at the data center. Although the hardware then was far less powerful than today's servers, the requirements imposed on the server were also considerably lower: Web 1.0 was just ramping up to speed, with no sign of Web 2.0. Websites with Flash were spectacular and the exception rather than the rule.

At the time, not everybody needed their own website, and especially not their own (virtual) server. People who wanted to run a website or a server quite frequently relied on free hosting offerings that existed at the time.

It was precisely these web hosting providers that first had the idea of using containers, even though they didn't use this term at the time. Driven by the need to host multiple customers on a physical server at the same time (instead of buying a separate server for each customer), they started creating containers.

The idea of Linux-VServer was born. The intent was for individual customers to have their own filesystems while sharing the hardware with other customers. Come what may, no user was to be able to escape from their own Linux-VServer and see what other customers were doing on the same hardware.

The result of development efforts was a fairly large kernel patch that is still needed today to use Linux-VServer meaningfully. Remember that when Linux-VServer started to get up to speed, the Linux kernel showed no sign of any appropriate functionality. Although that' no longer true now, the Linux-VServer developers have not yet made any attempt to modify their project to reflect the changed circumstances. If you want a Linux-VServer-capable kernel, you typically have no alternative but to build it yourself. That said, the developers do provide a patch for Linux 3.18 on their website [2].

Although Linux-VServer setups are still in use and actively maintained today, there is no concealing the fact that the project website looks fairly jaded, and the last posts in the news section or wiki are pretty old – a couple of years old, in fact.

At the end of the day, Linux-VServer seems to be somewhat out of time. The overhead of patching the kernel does not pay dividends, and administrators would do better to choose one of the solutions that is based on kernel functionality.

Buy this article as PDF

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

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Container Virtualization Comeback with Docker
    Docker helps the Linux container achieve an appealing comeback and integrates some features missing from earlier container solutions.
  • Operating system virtualization with OpenVZ
    The virtualization technology market is currently concentrating on hypervisor-based systems, but hosting providers often use an alternative technology. Container-based solutions such as OpenVZ/Virtuozzo are the most efficient way to go if the guest and host systems are both Linux.
  • LXC 1.0
    LXC 1.0, released in early 2014, was the first stable version for managing Linux containers. We check out the lightweight container solution to see whether it is now ready for production.
  • Improving Docker security now and in the future
    The focus for container solutions such as Docker is increasingly shifting to security. Some vulnerabilities have been addressed, with plans to take further steps in the future to secure container virtualization.
  • Application virtualization with Docker
    Half-lives of products are becoming shorter and shorter on today's virtualization market. This year, the buzz is all about Docker.
comments powered by Disqus