Changes

= OpenVZ is an open source virtualization technology for Linux Containers technology whitepaper = that enables the partitioning of a single physical Linux machine into multiple smaller independent units called containers.

OpenVZ is a virtualization technology for Linux, which lets one to partition a single physical Linux machine into multiple smaller units called containers. Technically, it OpenVZ consists of three major building blocks:

* Checkpointing/ live migration

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 namespace is associated with that namespace. The same identifier can be independently defined in multiple namespaces. An example of namespace is a feature 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 As an example of namespace usage, let's take a namespace is look at chroot.

[[Image:Chroot.png|right|200px400px]]

Chroot is still used for application isolation. For example(although, running ftpd in a unlike container, it does not provide full isolation — an application can escape from chroot to avoid a potential security breachunder certain circumstances).

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»is “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 not see each other's files.

* '''File system Process ID namespace''' — : this one is chrootso that every container processes has its own unique process IDs, and the first process inside a container has a PID of 1 (it is usually <code>/sbin/init</code> process which actually relies on its PID to be 1) itself. For every process in container, its PID in container is different from the one at host. Containers can only see their own processes, making sure containers and they can't see each (or access in any way, like sending signals) processes in other's filescontainers.

* '''Process ID IPC namespace''', : this is so in that every container processes have has its own unique process IDs, and the first process inside a container have a PID of 1 System V IPC (it is usually /sbin/init process which actually relies on its PID to be 1Inter-Process Communication). Containers can only see their own processesshared memory segments, semaphores, and they can't see (or access in any waymessages. For example, say by sending a signal) processes <code>ipcs</code> output is different in other containersevery container.

* '''IPC Networking namespace''', : this is so that every container have has its own IPC network devices, IP addresses, routing rules, firewall (Inter-Process Communicationiptables) shared memory segments, semaphoresrules, network caches and messagesso on. See more details below at [[#Networking]].

* '''Networking namespace<code>/proc</code> and <code>/sys</code> namespaces''', : this is so that every container to have its own network devicesrepresentation of <code>/proc</code> and <code>/sys</code> — special filesystems used to export some kernel information to applications. In a nutshell, IP addresses, routing rules, firewall (iptables) rules, network caches and so onthose are subsets of what a physical Linux host system have.

* '''<code>/proc</code> and <code>/sys</code> namespacesUTS namespace''', for : this is so that every container to can 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 host system havehostname.

* '''UTS namespace''', and so every container can have its own hostnameon.

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. Single kernel approach is much more light-weight than traditional VM-style virtualization (for more differences between CT and VM, see [[../Containers vs VMs/]]). The consequences of having only one kernel are:

Single kernel approach # A container can only run the same OS as the host, i.e. Linux in case of OpenVZ. Nevertheless, multiple different Linux distributions can be used in different containers. For example, RHEL4, RHEL5, RHEL6, Fedora 14 and Ubuntu 10.10 can run inside different containers on the same host system (running e.g. Gentoo).# Waiving the need to run multiple OS kernels leads to '''higher density''' of containers (compared to VMs). Practically that means that a few hundreds of typical containers can be started on a conventional notebook.# Software stack that lies in between the hardware and an end-user application is much more lightas thin as in usual non-weight than traditional VM-style virtualized system (see the image), this means native performance of containers and no virtualizationoverhead (compared to VMs). The consequences of having only one kernel are:

See more at [[# Waiving the need to run multiple OS kernels leads to '''higher Performance and density''' of containers (compared to VMs)# Software stack that lies in between an application and the hardware is much thinner, this means higher performance of containers (compared to VMs)# A container can only run Linux]] below.

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

* if a resource is not used, it it is available. Let's see what resources are controlled and howfor other containers, which makes resource overcommitting easy.

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).

* '''VCPU affinity''': tells the kernel a maximum number of CPUs a container can use. The difference from the previous option is you are not able to specify the exact CPUs, only the number of those, and then the kernel dynamically assigns / adjusts CPUs between containers based on current load.

==== * '''Disk space ===='''. In a default setup, all containers reside on the same hard drive partition (since a container is just a subdirectory). OpenVZ introduces a per-container disk space limit to control disk usage. So, to increase the disk space available to a container, one just needs to increase that limit -- dynamically, on the fly, without a need to resize a partition or a filesystem.

In a default setup* '''Disk I/O priority'''. Containers compete for I/O operations, all containers reside on and can affect each other if they use the same hard disk drive partition (since a container is just a subdirectory).OpenVZ introduces a per-container disk space limit I/O priority, which can be used to control disk usagee.g. So, to increase decrease the disk space available"bad guy" I/O rate in order to a container, one just needs to increase that limit -- dynamically, on not trash the fly, without a need to resize a partitionor a filesystemother containers.

==== * '''Disk I/O priority ====bandwidth'''. I/O bandwidth (in bytes per second) can be limited per-container.

Two major memory resource control parameters that are controlled per container are RAM and swap. If container is off its limit in terms of RAM, kernel tries to free some, by either shrinking the page cache or by swapping out. This reclamation mechanism is the same as used by a non-containerized kernel, the only difference is swap out is "virtual", in a sense that kernel does not write physical pages to the disk, but just removes those from container context (in order to avoid unnecessary I/O bandwidth ), while slowing down a container (in bytes per secondto emulate the effect of real swap out) can be limited . Next, if a situation of global (not per-container (currently only available in commercial Parallels Virtuozzo Containers)memory shortage happens, such pages are really swapped out into a swap file on disk.

All In addition, there is an ability to fine-grain control some of the containers share the same physical memory and swap space-related resources, such as size of IPC shared memory mappings, network buffers, number of processes etc, and other similar resources like a page cacheoverall about 20 parameters called User Beancounters. FIXME

[[Image:CT-networking.png|right]]=== Containers overhead Networking ===

OpenVZ works almost as fast as a usual Linux systemEach container has their own network stack. The only overhead is for networking and additional resource management This includes network device(s), routing table, firewall rules (see belowiptables), and in most cases network caches, hash tables, etc. From the perspective of container owner it is negligiblelooks like a standalone Linux box.

Three major modes of operation are possible. === OpenVZ = Route-based (venet) ==== This mode works in Layer 3 (network layer) of [[w:OSI model]]. That means that a container have a MAC-less network device (called <code>venet</code>) with one end in container and another end in the host system. Host system then acts as a router. Each IP packet is traversing both host and container's IP stack. The major features of this setup are:* '''Host system scope acts as a router'''* '''High security'''. It's the host system administrator who specifies container IP(s) and routing rule(s). No spoofing or harming is possible.* '''High control'''. Host system administrator fully controls container networking, by means of routing, firewall, traffic shaper etc.* '''No MAC address'''. A container can not use broadcasts or multicasts (since these features are on Level 2 and require a MAC address). ==== Bridge-based (veth) ==== This mode works in OSI Layer 2 (data link layer). For container, a Virtual Ethernet (<code>veth</code>) device is used. This device can be thought of as a pipe with two ends -- one end in the host system and another end in a CT, so if a packet goes to one end it will come out from the other end. The host system acts as a bridge, so veth is usually bridged together with eth0 or similar interface. The major features of this setup are:* '''Host system acts as a bridge'''* '''High configurability''': container administrator can setup all the networking.* '''Ability to use broadcasts/multicasts'''.* '''DHCP''' and dynamic IP addresses are possible* Broadcasting have negative performance impact (it is delivered separately to each CT) ==== Real network device in a container ====

From the host Host system, all containers processes are visibleadministrator can assign a network device (such as <code>eth1</code>) into a container. Container administrator can then manage it as usual.

* Container is constrained by limits set by host system administrator. That includes usage of CPU, memory, disk space and bandwidth, network bandwidth etc.t * Container OpenVZ container only runs Linux (Windows or FreeBSD is not an option), although different distributions is not an issuerun perfectly .

* Container By default, container can't set system time. Such permission should be explicitly granted by host system administrator. * By default, unless explicitly configured container does not have direct access to do so hardware such as hard drive, network card, or a PCI device. Such access can be granted by host system administrator if needed. === OpenVZ host system scope === From the host system, all containers processes are visible, and all the container files are accessible (say under <code>/vz/root/$CTID</code>). Host system administrator can set containers' parameters, access all containers files, send signals to run containers processes etc.  Containers mass-management is easy with some shell scripting and commands like <code>ntpdexec</code> in and <code>enter</code>. For example, to add a CT).user jack to all running containers the following command can be used: