1.3. OS Virtualization Layer

This section provides detailed information on the OS virtualization layer responsible for providing support for Virtuozzo containers.

1.3.1. Basics of OS Virtualization

The OS virtualization allows you to virtualize physical servers on the operating system (kernel) layer. The diagram below shows the basic architecture of OS virtualization.

../_images/osvirtualization.png

The OS virtualization layer ensures isolation and security of resources between different containers. The virtualization layer makes each container appear as a standalone server. Finally, the container itself houses its own applications and workload. OS virtualization is streamlined for the best performance, management, and efficiency. Its main advantages are the following:

  • Containers perform at levels consistent with native servers. Containers have no virtualized hardware and use native hardware and software drivers.
  • Each container can seamlessly scale up to the resources of an entire physical server.
  • OS virtualization technology provides the highest density available from a virtualization solution. You can create and run hundreds of containers on a standard production physical server.
  • Containers use a single OS, making it extremely simple to maintain and update across containers. Applications may also be deployed as a single instance.

1.3.2. Virtuozzo Containers

From the point of view of applications and container users, each container is an independent system. This independence is provided by the Virtuozzo OS virtualization layer. Note that only a negligible part of the CPU resources is spent on virtualization. The main features of the virtualization layer implemented in Virtuozzo are the following:

  • A container looks like a normal Linux system. It has standard startup scripts; software from vendors can run inside containers without any modifications or adjustment.
  • A user can change any configuration file and install additional software inside containers.
  • Containers are fully isolated from each other (file system, processes, sysctl variables).
  • Containers share dynamic libraries, which greatly saves memory.
  • Processes belonging to a container are scheduled for execution on all available CPUs. Consequently, containers are not bound to only one CPU and can use all available CPU power.

The two key parts of any container are the contents and configuration. By default, all container files are stored in the /vz/private/<UUID> directory on the hardware node, also called private area.

File Name Description
/vz/private/<UUID> Container private area.
/vz/private/<UUID>/root.hdd/root.hdd Virtual hard disk with container contents. The maximum size of the virtual hard disk is 50 TB.
/vz/root/<UUID> Container mount point.
ve.conf

Container configuration file:

  • Is symlinked to /etc/vz/conf/<UUID>.conf
  • Defines container parameters, such as allocated resource limits, IP address and hostname, and so on.
  • Overrides matching parameters in the global configuration file.

All container files are stored in a single image (/vz/private/<UUID>/root.hdd/root.hdd), similar to a virtual machine’s hard disk. Such standalone nature:

  • Enables easier migrations and backups due to a faster sequential I/O access to container images than to separate container files.
  • Removes the need for OS and application templates once a container is created.
  • Allows the use of native Linux disk quotas that are journaled and does not require quota recalculation after disasters like server crashes.

Note

Using containers that store all files in an image file (also known as containers with the container-in-an-image-file layout) is supported only for /vz partitions formatted as ext4.

1.3.2.1. Virtuozzo Container Hardware

A container may have the following virtual hardware:

Hardware Theoretical Certified
CPU Up to the total number of threads on the host Up to 64
RAM Up to total amount of physical RAM on the host Up to 1 TB
Disk drives Up to 15: hard disk drives mapped to QCOW2 image files and DVD drives mapped to ISO image files, up to 50 TB each
Network Interfaces Up to 15

1.3.3. Memory and IOPS Deduplication

Virtuozzo provides memory and IOPS deduplication that helps save memory and IOPS on the server and increases the maximum number of running containers per server.

Deduplication is provided by Virtuozzo File Cache which includes the pfcached daemon and a ploop image mounted to a directory on the server. The file cache ploop contains copies of eligible files located inside containers. To be eligible for caching, files in containers must meet certain configurable requirements, e.g., be read in a certain number of containers, be of certain size, be stored in certain directories in containers.

When the kernel gets a request to read a file located in a container ploop, it searches the file cache ploop for a copy of that file by the SHA1 hash stored as file’s extended attribute. If successful, the copy in the file cache ploop is read instead of the original file in the container ploop. Otherwise, the original file in the container ploop is read.

To populate the file cache ploop with most requested files, pfcached periodically obtains container files read statistics from kernel, analyzes it, and copies files which are eligible to the file cache ploop. If the file cache ploop is running out of space, the least recently used files are removed from it.

Virtuozzo File Cache offers the following benefits:

  • Memory deduplication. Only a single file from the file cache ploop needs to be loaded to memory instead of loading multiple identical files located in multiple containers.
  • IOPS deduplication. Only a single file from the file cache ploop needs to be read instead of reading multiple identical files located in multiple containers.

If the physical server has storage drives of various performance, e.g., IDE and SSD, the file cache ploop performs better if located on the fastest storage drive on the node, e.g., SSD. In any case:

  • If the server memory is not overcommitted, the file cache mostly helps speed up container start during which most files are read. In this case caches residing in memory are not cleaned often, so copies in the file cache ploop, once read during container start, do not need to be reread often during container operation.
  • If the server memory is overcommitted, Virtuozzo File Cache helps speed up both container start and operation. In this case, caches residing in memory may be cleaned often, so files in the file cache ploop need to be reread as often.

Virtuozzo File Cache can be managed with the pfcache utility.

1.3.4. Templates

A template (or a package set) in Virtuozzo is a set of original application files repackaged for use by Virtuozzo. Usually, it is just a set of RPM packages for Red Hat like systems. Virtuozzo provides tools for creating templates, installing, upgrading, adding them to and removing them from a container.

Using templates lets you:

  • Share RAM among similar applications running in different containers to save hundreds of megabytes of memory.
  • Deploy applications simultaneously in many containers.
  • Use different versions of an application in different containers (for example, perform upgrades only in certain containers).

There are two types of templates: OS and application.

  • An OS template is an operating system and the standard set of applications to be found right after the installation. Virtuozzo uses OS templates to create new containers with a preinstalled operating system.
  • An application template is a set of repackaged software packages optionally accompanied with configuration scripts. Application templates are used to add extra software to existing containers.

For example, you can create a container on the basis of the redhat OS template and add the MySQL application to it with the help of the mysql template.