Changes

OpenVZ is a an open source virtualization technology for Linux, which lets one to partition that enables the partitioning of a single physical Linux machine into multiple smaller independent units called containers.

Technically, it OpenVZ consists of three major building blocks:

A namespace is an abstract environment created to hold a logical grouping of unique identifiers or symbols (i.e., names). An identifier defined in a feature namespace is associated with that namespace. The same identifier can be independently defined in multiple namespaces. An example of namespace is a directory on a file system. This allows two files with the same name to limit be stored on the scope of somethingsame device as long as they are stored in different directories. Here For OpenVZ, Linux kernel namespaces are used as containers building blocks. A simple case of a namespace is chroot.

Chroot is still used for application isolation. For example(although, running ftpd in a chroot to avoid a potential security breachunlike container, it does not provide full isolation).

Chroot is also used in by containers, which have so a container filesystem is just a directory on the following consequenceshost. Consequences are:

* there is no need for a separate block device, hard drive partition or filesystem-in-a-file setup.

OpenVZ builds on a chroot idea and expands it to everything else that applications have. In other words, every API that kernel provides to applications are «namespaced»“namespaced”, making sure every container have its own isolated subset of a resource. Examples include:

* '''File system namespace''' — : this one is <code>chroot() </code> itself, making sure containers can't not see each other's files.

* '''Process ID namespace''', : this is so in that every container processes have has its own unique process IDs, and the first process inside a container have has a PID of 1 (it is usually <code>/sbin/init </code> process which actually relies on its PID to be 1). Containers can only see their own processes, and they can't see (or access in any way, say by sending a signal) processes in other containers.

* '''IPC namespace''', : this is so that every container have has its own IPC (Inter-Process Communication(IPC) shared memory segments, semaphores, and messages.

* '''Networking namespace''', : this is so that every container have has its own network devices, IP addresses, routing rules, firewall (iptables) rules, network caches and so on.

* '''<code>/proc</code> and <code>/sys</code> namespaces''', for : this is so that every container to have their its own representation of <code>/proc</code> and <code>/sys</code> — special filesystems used to export some kernel information to applications. In a nutshell, those are subsets of what a physical Linux host system have.

* '''UTS namespace''', : this is so that every container can have its own hostname.

Note that memory and CPU need not be namespaced. Existing : existing virtual memory and multitask mechanisms are already taking care of itaddress this.

To put it simplesimply, a container is a sum of all the its namespaces. Therefore, there is only one single OS kernel running, and on top of that it there are multiple isolated containers, sharing that single kernel.

# Waiving the need to run multiple OS kernels leads to '''higher density''' of containers (compared to VMs). # Software stack that lies in between the hardware and an end-user application and is as thin as in usual non-virtualized system (see the hardware is much thinnerimage), this means higher performance of containers (compared to VMs)# A container can only run the same OS as the host, i.e. Linux in case of OpenVZ. Nevertheless, multiple different Linuxdistributions can be used in different containers.

It is important to understand that resources are not pre-allocated, but they are just limited. That means:

Kernel CPU scheduler is modified to be containers-aware. When it is a 's time for a context switch, scheduler decides which task selects a process to give a CPU time slice to. Traditional A traditional scheduler just chooses one among all the runnable tasks in the system. OpenVZ scheduler implements two-level schema: it chooses a container first, then it chooses a task inside the container. That way, all the containers get a fair share of CPU resources (with no regard to number of processes inside each container).

* Container OpenVZ container only runs Linux (Windows or FreeBSD is not an option), although different distributions is not an issue.