Container Service

Hypervisor-based virtualization solutions are all the rage. Many companies use Xen, KVM, or VMware to gradually abstract their hardware landscape from its physical underpinnings. The situation is different if you look at leased servers, however. People who decide to lease a virtual server (vserver) are not typically given a fully virtualized system based on Xen or ESXi, and definitely not a root server. Instead, they might be given a resource container, which is several magnitudes more efficient for Linux guest systems and also easier to set up and manage. A resource container can be implemented using Linux-Vserver [1], OpenVZ [2], or Virtuozzo [3].

Benefits

Hypervisor-based virtualization solutions emulate a complete hardware layer for the guest system; ideally any operating system including applications can be installed on the guest, which will seem to have total control of the CPU, chipset, and peripherals. Assuming you have state-of-art hardware (a CPU with a virtualization extension – VT), the performance is good; however, hypervisor-based systems do have some disadvantages. Because each guest installs its own operating system, it will perform many tasks in its own context just like the host system does, meaning that some services might run multiple times. This can impact performance due to overlapping – one example of this being cache strategies for the hard disk subsystem. Caching the emulated disks on the guest system is a waste of time because the host system already does this, and emulated hard disks are actually just files on the filesystem.

Parallel Universes

Resource containers use a different principle based on the fact that – from the application's point of view – every operating system comprises a filesystem with installed software, space for data, and a number of functions for accessing devices. For the application, all of this appears to be a separate universe. A container has to be designed so that the application thinks it has access to a complete operating system with a runtime environment.

From the host's point of view, containers are simply directories. Because all the guests share the same kernel, they can only be of the same type as the host operating system or its kernel. This means that a Linux-based container solution like OpenVZ can only host Linux guests. From a technical point of view, resource containers extend the host system's kernel, adding an abstraction layer than isolates the containers from one another and provides resources, such as CPU cycles, memory, and disk capacity (Figure 1).

Figure 1: In virtualization based on resource containers, the host and guest use the same kernel. This means that a Linux host can only support Linux guests.

Installing a container means creating a sub-filesystem in a directory on the host system, such as /var/lib/vz/gast1; this is the root directory for the guest. Below /var/lib/vz/gast1 there is a regular Linux filesystem hierarchy but without a kernel, just like in a normal chroot environment.

The container abstraction layer makes sure that the guest system sees its own process namespace with separate process IDs. On top of this, the kernel extension that provides the interface is required to create, delete, shut down and assign resources to containers. Because the container data is extensible on the host file system, resource containers are easy to manage from within the host context.

Efficiency

Resource containers are magnitudes more efficient than hypervisor systems because each container uses only as many CPU cycles and as much memory as its active applications need. The resources they abstraction layer itself needs are negligible. The Linux installation on the guest only consumes hard disk space. However, you can't load any drivers or kernels from within a container. The predecessors of container virtualization in the Unix world are technologies that have been used for decades such as chroot (Linux), jails (BSD), or Zones (Solaris). With the exception of (container) virtualization in User-Mode Linux [4], only a single host kernel runs with resource containers.