Article ID: 112740, created on Nov 13, 2012, last review on Aug 12, 2014

  • Applies to:
  • Virtuozzo
  • Virtuozzo containers for Linux
  • Virtuozzo hypervisor

General information

There are several resource management schemas in Parallels Virtuozzo Containers (PVC) for Linux and Parallels Server Bare Metal (PSBM) products. This article will help you understand the general ideas behind each schema and select the appropriate product version that addresses your needs in the most convenient way.

You are advised to learn the meanings of these terms before reading on:

Memory allocation - The process of reserving virtual memory by means of standard tools like malloc(3)

Memory consumption (or usage) - The process of storing data within allocated memory

Generally, not all allocated memory is actually used, which is why it is possible to allocate much more memory than is available on the machine.

Parallels Virtuozzo Containers for Linux and Parallels Server Bare Metal products allow you to manage both memory allocation and consumption.

A situation where the total memory consumption limit for all containers exceeds the physically available amount of memory (RAM+swap) is called "overselling" (or overbooking, overcommitment, etc.).

It is recommended to set the memory consumption limit so that total memory consumption will not exceed the physically available memory.

Since Parallels Virtuozzo Containers for Linux 4.7 and Parallels Server 5 Bare Metal, there is a container configuration parameter called VM_OVERCOMMIT, which shows the actual difference between the amount of memory allowable for allocation and the amount of memory allowable for consumption.

Previous versions did not have such a tool to quickly scale memory allocation and memory consumption limits.

Hereinafter, overcommit implies the difference between the memory allocation limit and the memory consumption limit.

Memory management schemas

User Beancounters (UBC)

The initial system of resource management introduced in Parallels Virtuozzo Containers and OpenVZ was UBC. It allows you to granularly tune container resource allocation and consumption limits and guarantees.

The main advantage of the system is the ability to perform a granular tuning of a container to meet the needs of a particular application set installed inside the container.

The main disadvantage of the system is that it operates in terms of the Linux kernel and is not intuitive for a user. Also, it is necessary to set up limits very carefully to be able to control memory and other resource allocations and consumption parameters.

A description of all UBC parameters can be found in this article:
112807 UBC resources in Parallels Virtuozzo Containers for Linux

Service Level Management (SLM)

The SLM system was introduced in Parallels Virtuozzo Containers for Linux 3.x (also available in Parallels Server 4 Bare Metal) and has become obsolete in Parallels Virtuozzo Containers for Linux 4.7 and Parallels Server 5 Bare Metal. It was developed to simplify resource management in comparison to the UBC system by computing a single parameter, slmmemorylimit. The major difference between SLM and UBC is that in SLM, there is only one limit, slmmemorylimit, allowing you to quickly configure memory resources for a container. The parameter has average and instant limits, which work completely differently from barrier and limit in UBC.

The average parameter defines the allowed memory consumption for a container, similarly to (but not exactly the same as) oomguarpages in UBC. 

The instant parameter defines the maximum allowed memory consumption for a container. The container cannot use memory above the limit (however, it still can allocate memory beyond this limit).

SLM checks the memory configuration on the server every 15 seconds -- with a so-called "tick" -- and preforms configured actions based on the current overall state on the node. If the memory usage is higher than the average limit based on the previous states, the container's processes will be killed, like in the real system when the kernel needs some free space for its own needs. The algorithm for the process selection is the same as in the generic Linux OOM killer.

The container cannot use allocated memory above the instant memory limit -- once the usage is equal to this limit and there is a request to get more memory, SLM will terminate the process(es) until the usage is below the average limit.

It is strongly recommended to set average and instant limits to the same values to avoid frequent process kills.

The main advantages of the SLM system include the simple resource limitation and the ability to work together with UBC resources for fine-tuning a container.

The main disadvantages of the SLM system are difficult-to-interpret average and instant limit behavior and unpredictable behavior in the event of a physical resources shortage.


With consideration to the strong and weak points of SLM and UBC, a new schema called vSwap has been introduced since Parallels Virtuozzo Containers for Linux 4.7 and Parallels Server 5 Bare Metal.

The system replaces the SLM schema with the vSwap schema during upgrades from previous PVCfL versions.

SLM and UBC container limits are read and converted to internal vSwap limits during CT startup; no changes to config files are made unless vSwap settings are set manually.

The vSwap schema allows one to quickly configure a container's RAM and swap limits and set up memory overcommitment, while other parameters are calculated by Parallels Virtuozzo Containers for Linux on the fly.

However, if more granular tuning is required, other UBC settings can be configured as well. Container configuration parameters override those calculated on the fly.

Additional information

For more information, refer to the following sources:
1354 What are User Beancounters?
112807 UBC resources in Parallels Virtuozzo Containers for Linux

Parallels Virtuozzo Containers 4.7 for Linux User's Guide
Administrator's Guide to Managing UBC Resources
Parallels Virtuozzo Containers 4.6 for Linux User's Guide
OpenVZ wiki

0dd5b9380c7d4884d77587f3eb0fa8ef 2897d76d56d2010f4e3a28f864d69223 e8e50b42231236b82df27684e7ec0beb d02f9caf3e11b191a38179103495106f a26b38f94253cdfbf1028d72cf3a498b

Email subscription for changes to this article
Save as PDF