Features - Revision history

110.225.40.20 at 02:18, 18 November 2011

2011-11-18T02:18:07Z

110.225.40.20 at 02:17, 18 November 2011

2011-11-18T02:17:12Z

92.195.105.89: /* OS Virtualization */ (CT)

2010-01-12T13:15:35Z

‎OS Virtualization: (CT)

Kir: Reverted edits by 122.200.19.2 (Talk) to last version by Kir

2009-12-13T11:32:33Z

Reverted edits by 122.200.19.2 (Talk) to last version by Kir

122.200.19.2 at 06:49, 13 December 2009

2009-12-13T06:49:00Z

Kir: /* OS Virtualization */ link to correct article

2008-04-28T08:41:52Z

‎OS Virtualization: link to correct article

Toutoune25: typo

2008-04-28T08:32:34Z

typo

Gjanssens: /* Checkpointing and live migration */ - fix small typo

2008-02-20T16:41:24Z

‎Checkpointing and live migration: - fix small typo

Kir: /* Checkpointing and live migration */ VE -> container

2008-01-24T15:34:55Z

‎Checkpointing and live migration: VE -> container

Kir: /* OS Virtualization */ VE -> container

2008-01-24T15:34:26Z

‎OS Virtualization: VE -> container

← Older revision		Revision as of 02:18, 18 November 2011
Line 1:		Line 1:
−	The architecture of OpenVZ is ~~are~~ different from the traditional virtual machines architecture because it always runs the same OS kernel as the host system (while still allowing multiple Linux distributions in individual [[container]]s). This single-kernel implementation technology enables running [[container]]s with a near-zero overhead. Thus, OpenVZ offer an order of magnitude higher efficiency and manageability than traditional virtualization technologies.	+	The architecture of OpenVZ is different from the traditional virtual machines architecture because it always runs the same OS kernel as the host system (while still allowing multiple Linux distributions in individual [[container]]s). This single-kernel implementation technology enables running [[container]]s with a near-zero overhead. Thus, OpenVZ offer an order of magnitude higher efficiency and manageability than traditional virtualization technologies.

	== OS Virtualization ==		== OS Virtualization ==

← Older revision		Revision as of 02:17, 18 November 2011
Line 1:		Line 1:
−	The architecture of OpenVZ is different from the traditional virtual machines architecture because it always runs the same OS kernel as the host system (while still allowing multiple Linux distributions in individual [[container]]s). This single-kernel implementation technology enables running [[container]]s with a near-zero overhead. Thus, OpenVZ offer an order of magnitude higher efficiency and manageability than traditional virtualization technologies.	+	The architecture of OpenVZ is are different from the traditional virtual machines architecture because it always runs the same OS kernel as the host system (while still allowing multiple Linux distributions in individual [[container]]s). This single-kernel implementation technology enables running [[container]]s with a near-zero overhead. Thus, OpenVZ offer an order of magnitude higher efficiency and manageability than traditional virtualization technologies.

	== OS Virtualization ==		== OS Virtualization ==

@@ Line 4: / Line 4: @@
 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]] 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 [[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;
 * [[Container]]s are completely isolated from each other (file system, processes, Inter Process Communication (IPC), sysctl variables);

@@ Line 1: / Line 1: @@
 The architecture of OpenVZ is different from the traditional virtual machines architecture because it always runs the same OS kernel as the host system (while still allowing multiple Linux distributions in individual [[container]]s). This single-kernel implementation technology enables running [[container]]s with a near-zero overhead. Thus, OpenVZ offer an order of magnitude higher efficiency and manageability than traditional virtualization technologies.
-== OS Virtualization O==
+== OS Virtualization ==
 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:

@@ Line 1: / Line 1: @@
 The architecture of OpenVZ is different from the traditional virtual machines architecture because it always runs the same OS kernel as the host system (while still allowing multiple Linux distributions in individual [[container]]s). This single-kernel implementation technology enables running [[container]]s with a near-zero overhead. Thus, OpenVZ offer an order of magnitude higher efficiency and manageability than traditional virtualization technologies.
-== OS Virtualization ==
+== OS Virtualization O==
 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:

@@ Line 6: / Line 6: @@
 * A [[container]] 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;
-* [[Containers]]s are completely isolated from each other (file system, processes, Inter Process Communication (IPC), sysctl variables);
+* [[Containers]] 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.

@@ Line 61: / Line 61: @@
 {{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 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 (restored) there. The delay is about a few seconds, and it is not a downtime, just a delay.
+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 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 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.

@@ Line 61: / Line 61: @@
 {{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 VE from one physical server to another without a need to shutdown/restart a container. The process is known as checkpointing: a CT is freezed 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 (restored) there. The delay is about a few seconds, and it is not a downtime, just a delay.
+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 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 (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.
-That feature makes possible scenarios such as upgrading your server without any need to reboot it: if your database needs more memory or CPU resources, you just buy a newer better server and live migrate your container to it, then increase its limits. If you want to add more RAM to your server, you migrate all VEs to another one, shut it down, add memory, start it again and migrate all containers back.
+That feature makes possible scenarios such as upgrading your server without any need to reboot it: if your database needs more memory or CPU resources, you just buy a newer better server and live migrate your container to it, then increase its limits. If you want to add more RAM to your server, you migrate all containers to another one, shut it down, add memory, start it again and migrate all containers back.
 [[Category: Concepts]]
 [[Category: Technology]]