WP/Containers vs VMs - Revision history

Kir: fix examples of VM

2015-05-08T20:46:07Z

fix examples of VM

Sergey Bronnikov: Parallels -> Odin

2015-05-08T11:39:02Z

Parallels -> Odin

Kir: fix a link

2014-04-02T16:54:38Z

fix a link

Kir: /* Memory management */ some more random ideas on MM

2011-05-12T18:06:16Z

‎Memory management: some more random ideas on MM

Kir: +Networking

2011-05-11T17:51:01Z

+Networking

Dev at 14:50, 11 April 2011

2011-04-11T14:50:59Z

Kir: added a choot png

2011-03-25T17:29:33Z

added a choot png

Kir: fixed link, hightighted high perf

2011-03-25T17:28:08Z

fixed link, hightighted high perf

Kir: some more stuff

2011-03-25T17:25:03Z

some more stuff

Kir: just a placeholder for now

2011-03-15T14:38:49Z

just a placeholder for now

New page

= 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

@@ Line 1: / Line 1: @@
 = Containers versus Virtual Machines =
-This article gives an overview of containers for those who know what a Virtual Machine (VM) is. VMs are implemented by products such as VMware, Odin, Xen, Hyper-V, Virtual Box etc. If you do not have experience with those or similar products, better read [[../What are containers/]] whitepaper.
+This article gives an overview of containers for those who know what a Virtual Machine (VM) is. VMs are implemented by products such as VMware, KVM, Xen, Parallels Desktop, Hyper-V, Virtual Box etc. If you do not have experience with those or similar products, better read [[../What are containers/]] whitepaper.
 Containers are very similar to VMs in a sense that they also let one to partition one physical computer into multiple small isolated partitions (called VMs or containers).

@@ Line 1: / Line 1: @@
 = Containers versus Virtual Machines =
-This article gives an overview of containers for those who know what a Virtual Machine (VM) is. VMs are implemented by products such as VMware, , Parallels, Xen, Hyper-V, Virtual Box etc. If you do not have experience with those or similar products, better read [[../What are containers/]] whitepaper.
+This article gives an overview of containers for those who know what a Virtual Machine (VM) is. VMs are implemented by products such as VMware, Odin, Xen, Hyper-V, Virtual Box etc. If you do not have experience with those or similar products, better read [[../What are containers/]] whitepaper.
 Containers are very similar to VMs in a sense that they also let one to partition one physical computer into multiple small isolated partitions (called VMs or containers).

@@ Line 31: / Line 31: @@
 An operating system deployed inside VM assumes it it is running on top of the real hardware, therefore VM needs to emulate a real physical network card (NIC). All the traffic should go through both the real NIC and the virtual NIC. This creates some noticeable overhead, which could be mitigated by using paravirtualized NIC driver inside VM (i.e. driver that is aware of the hypervisor and therefore can use). Paravirtualized NIC driver can not always be used as it is specific to a guest OS/version. See [[Performance/Network Throughput]] for network performance comparison between OpenVZ and various hypervisor products.
-In case of containers, no virtual NIC is needed (naturally, there can be no hardware drivers inside a container). Instead, a kernel is letting a container to use a network interface, which can or can not be directly attached to a real network card. The difference from VM case is there is no hardware emulation of any kind. See more at [[What are containers#Networking|Networking chapter of What are containers]].
+In case of containers, no virtual NIC is needed (naturally, there can be no hardware drivers inside a container). Instead, a kernel is letting a container to use a network interface, which can or can not be directly attached to a real network card. The difference from VM case is there is no hardware emulation of any kind. See more at [[WP/What are containers#Networking|Networking chapter of What are containers]].
 In terms of network topology organization, there are no big differences between VMs and containers. In both cases one can use route-based (OSI level 3) or bridge-based (OSI level 2) networking.
@@ Line 51: / Line 51: @@
 == Density ==
-See [[WP/Containers density/]].
+See [[WP/Containers density]].
 == Performance ==
 See [[Performance]].

@@ Line 37: / Line 37: @@
 == Memory management ==
-In case of VMs, every guest operating system kernel "thinks" it is managing some hardware, including memory (RAM). It performs memory allocation, accounting, FIXME
+In case of VMs, every guest operating system kernel "thinks" it is managing some hardware, including memory (RAM). It performs memory allocation, accounting and so on.
 == Density ==

@@ Line 28: / Line 28: @@
 == Networking ==
 == Memory management ==
 == Density ==
-There is a separate article which explains differences in technologies and why containers are better in high density environments [[WP/Containers density]].
+See [[WP/Containers density/]].
 == Performance ==
-FIXME: link to performance paper
+See [[Performance]].

@@ Line 1: / Line 1: @@
 = Containers versus Virtual Machines =
-This article gives an overview of containers for those who know what a Virtual Machine (VM) is. VMs are implemented by products such as VMware, Xen, Hyper-V, Virtual Box, Parallels Desktop etc. If you do not have experience with those or similar products, better read [[../What are containers/]] whitepaper.
+This article gives an overview of containers for those who know what a Virtual Machine (VM) is. VMs are implemented by products such as VMware, , Parallels, Xen, Hyper-V, Virtual Box etc. If you do not have experience with those or similar products, better read [[../What are containers/]] whitepaper.
 Containers are very similar to VMs in a sense that they also let one to partition one physical computer into multiple small isolated partitions (called VMs or containers).
@@ Line 12: / Line 12: @@
 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:
+In contrast, OpenVZ and containers technology 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)
+# Waiving the need to run multiple OS kernels results in '''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)
@@ Line 26: / Line 26: @@
 * there is no I/O overhead (for VMs it can be as high as 1.5x to 3x, especially for small requests)
 * mass deployment is easy

@@ Line 18: / Line 18: @@
 == File system ==
+[[Image:chroot.png|300px|right]]
 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:

@@ Line 1: / Line 1: @@
 = Containers versus Virtual Machines =
 == Single kernel concept ==
@@ Line 17: / Line 24: @@
 * host system administrator can see all the containers' files
 * containers backup/restore is trivial
 * mass deployment is easy