Changes
no edit summary
From the point of view of applications and [[container]] users, each container is an independent system. This independence is provided by a virtualization layer in the kernel of the host OS. 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 OpenVZ are the following:
* A [[container]] (CT) looks and behaves like a regular Linux system. It has standard startup scripts; software from vendors can run inside a container without OpenVZ-specific modifications or adjustment;
* A user can change any configuration file and install additional software;
* [[ContainersContainer]]s are completely isolated from each other (file system, processes, Inter Process Communication (IPC), sysctl variables);
* Processes belonging to a container are scheduled for execution on all available CPUs. Consequently, [[CT]]s are not bound to only one CPU and can use all available CPU power.
{{Main|Checkpointing and live migration}}
A live migration and checkpointing feature was released for OpenVZ in the middle of April 2006. It allows to migrate a container from one physical server to another without a need to shutdown/restart a container. The process is known as checkpointing: a CT is freezed frozen and its whole state is saved to the file on disk. This file can then be transferred to another machine and a CT can be unfreezed unfrozen (restored) there. The delay is about a few seconds, and it is not a downtime, just a delay.
Since every piece of the container state, including opened network connections, is saved, from the user's perspective it looks like a delay in response: say, one database transaction takes a longer time than usual, when it continues as normal and user doesn't notice that his database is already running on the another machine.