6,534
edits
Changes
just a placeholder for now
= Containers versus Virtual Machines =
== Single kernel concept ==
Xen, KVM, VMware and other hypervisor-based products provide an ability to have multiple instances of virtual hardware (called VMs – Virtual Machines) on a single piece of real hardware. On top of that virtual hardware one can run any Operating System, so it's possible to run multiple different OSs on one single server. Each VM runs full software stack (including an OS kernel).
In contrast, OpenVZ uses a single-kernel approach. There is only one single OS kernel running, and on top of that there are multiple isolated instances of user-space programs. This approach is more lightweight than VM. The consequences are:
# Waiving the need to run multiple OS kernels leads to '''higher 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)
== File system ==
From file system point of view, a container is just a <code>chroot()</code> environment. In other words, a container file system root is merely a directory on the host system (usually /vz/root/$CTID/, under which one can find usual directories like <code>/etc</code>, <code>/lib</code>, <code>/bin</code> etc.). The consequences are:
* there is no need for a separate block device, hard drive partition or filesystem-in-a-file setup
* host system administrator can see all the containers' files
* containers backup/restore is trivial
* mass deployment is easy
== Single kernel concept ==
Xen, KVM, VMware and other hypervisor-based products provide an ability to have multiple instances of virtual hardware (called VMs – Virtual Machines) on a single piece of real hardware. On top of that virtual hardware one can run any Operating System, so it's possible to run multiple different OSs on one single server. Each VM runs full software stack (including an OS kernel).
In contrast, OpenVZ uses a single-kernel approach. There is only one single OS kernel running, and on top of that there are multiple isolated instances of user-space programs. This approach is more lightweight than VM. The consequences are:
# Waiving the need to run multiple OS kernels leads to '''higher 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)
== File system ==
From file system point of view, a container is just a <code>chroot()</code> environment. In other words, a container file system root is merely a directory on the host system (usually /vz/root/$CTID/, under which one can find usual directories like <code>/etc</code>, <code>/lib</code>, <code>/bin</code> etc.). The consequences are:
* there is no need for a separate block device, hard drive partition or filesystem-in-a-file setup
* host system administrator can see all the containers' files
* containers backup/restore is trivial
* mass deployment is easy
