OpenVZ

Each container is a separate entity, and behaves largely as a physical server would. Each has its own:

Files

System libraries, applications, virtualized /proc and /sys, virtualized locks, etc.

Users and groups

Each container has its own root user, as well as other users and groups.

Process tree

A container only sees its own processes (starting from init). PIDs are virtualized, so that the init PID is 1 as it should be.

Network

Virtual network device, which allows a container to have its own IP addresses, as well as a set of netfilter (iptables), and routing rules.

Devices

If needed, any container can be granted access to real devices like network interfaces, serial ports, disk partitions, etc.

IPC objects

Shared memory, semaphores, messages.

OpenVZ resource management consists of four components: two-level disk quota, fair CPU scheduler, disk I/O scheduler, and user bean counters (see below). These resources can be changed during container run time, eliminating the need to reboot.

Each container can have its own disk quotas, measured in terms of disk blocks and inodes (roughly number of files). Within the container, it is possible to use standard tools to set UNIX per-user and per-group disk quotas.

The CPU scheduler in OpenVZ is a two-level implementation of fair-share scheduling strategy.

On the first level, the scheduler decides which container it is to give the CPU time slice to, based on per-container cpuunits values. On the second level the standard Linux scheduler decides which process to run in that container, using standard Linux process priorities.

It is possible to set different values for the CPUs in each container. Real CPU time will be distributed proportionally to these values.

In addition to the above, OpenVZ provides[4] ways to:

• set strict CPU limits, such as 10% of a total CPU time (--cpulimit);
• limit number of CPU cores available to container (--cpus);
• bind a container to a specific set of CPUs (--cpumask).

Similar to the CPU scheduler described above, I/O scheduler in OpenVZ is also two-level, utilizing Jens Axboe's CFQ I/O scheduler on its second level.

Each container is assigned an I/O priority, and the scheduler distributes the available I/O bandwidth according to the priorities assigned. Thus no single container can saturate an I/O channel.

User Beancounters is a set of per-container counters, limits, and guarantees, meant to prevent a single container from monopolizing system resources. In current OpenVZ kernels (RHEL6-based 042stab*) there are two primary parameters (ram and swap, a.k.a. physpages and swappages), and others are optional.[5]

Other resources are mostly memory and various in-kernel objects such as Inter-process communication shared memory segments and network buffers. Each resource can be seen from /proc/user_beancounters and has five values associated with it: current usage, maximum usage (for the lifetime of a container), barrier, limit, and fail counter. The meaning of barrier and limit is parameter-dependent; in short, those can be thought of as a soft limit and a hard limit. If any resource hits the limit, the fail counter for it is increased. This allows the owner to detect problems by monitoring /proc/user_beancounters in the container.

A live migration and checkpointing feature was released for OpenVZ in the middle of April 2006. This makes it possible to move a container from one physical server to another without shutting down the container. The process is known as checkpointing: a container is frozen and its whole state is saved to a file on disk. This file can then be transferred to another machine and a container can be unfrozen (restored) there; the delay is roughly a few seconds. Because state is usually preserved completely, this pause may appear to be an ordinary computational delay.