Previous page

Next page

Locate page in Contents

Print this page

Parallels Containers

From the point of view of applications and Container users, each Container is an independent system. This independence is provided by the Parallels Cloud Server OS virtualization layer. Note that only a negligible part of the CPU resources is spent on virtualization (around 1-2%). The main features of the virtualization layer implemented in Parallels Cloud Server 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) and Parallels virtual machines.
  • 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/ <CT_ID> directory on the Parallels server, also called private area .

Key Container directories and files:

File Name

Description

/vz/private/ <CT_ID>

Container private area.

/vz/private/ <CT_ID> /root.hdd/root.hdd

Virtual hard disk with Container contents. The maximum size of the virtual hard disk is 16 TB.

/vz/root/ <CT_ID>

Container mount point.

ve.conf

Container configuration file:

  • Is symlinked to /etc/vz/conf/ <CT_ID> .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/ <CT_ID> /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.