Changes

== Techniques ==<!--T:2-->

=== Virtual machines (VMs) ===<!--T:3-->'''Virtual machines''' emulate some real or fictional hardware, which in turn requires real resources from the ''host'' (the machine running the VMs). This approach, used by most ''system emulators'', allows the emulator to run an arbitrary ''guest operating system'' without modifications because guest OS is not aware that it is not running on real hardware. :( The main issue with this approach is that some CPU instructions require additional privileges and may not be executed in user space thus requiring a ''virtual machines monitor'' (VMM) , also called a hypervisor, to analyze executed code and make it safe on-the-fly. Hardware emulation approach is used by [http://www.vmware.com/ VMware] products, [http://parallelswww.VirtualBox.org VirtualBox], [http://fabrice.bellard.free.fr/qemu/ QEMU], [http://www.virtuozzo.com/ ParallelsVirtuozzo] and [http://www.microsoft.com/windowsserversystem/virtualserver/default.mspx Microsoft Virtual Server]. :(

=== Paravirtualization === <!--T:) You changed topics 4-->This technique also requires a VMM, but most of its work is performed in the ''guest OS'' code, which in mid-paragraphturn is ''modified'' to support this VMM and avoid unnecessary use of privileged instructions. The paravirtualization technique also enables running different OSs on a single server, but requires them to be ported, i.e. These emulators they should «know» they are running under the hypervisor. The paravirtualization approach is used to create virtual machines, by products such as [http://dosboxwww.sourceforgexen.net/ DosBOXorg Xen]and [http://bochsuser-mode-linux.sourceforge.net/ BochsUML]. Virtual Machine emulators are able to run x86 code and OSs on a wide variaty of computer hardware, I.E. ppc/sparc/alpha.

The others you mention use cpu === Virtualization on the OS level, a.k.a. containers virtualization, Rather, guest code is executed as=== <!--T:5--is in >Most applications running on a safe VM environment managed by server can easily share a VM monitormachine with others, if they could be isolated and secured. Guest kernel code is executed at a less priviliged levelFurther, in most situations, causing privileged operations to generate exceptions which different operating systems are managed by not required on the VM monitorsame server, merely multiple instances of a single ''operating system''. Like OS-level virtualization systems have been designed to provide the abovementioned VMware required isolation and security to run multiple applications or copies of the same OS (but different distributions of the OS) on the same server. [http://openvz.org/ OpenVZ], [http://plex86www.sourceforgeswsoft.netcom/products/ Plex86virtuozzo Virtuozzo], [http://linux-vserver. Unlike bochs and dosboxorg/ Linux-VServer], instructions are not translated(emulation) into native code[http://www.sun. This means that vmware com/bigadmin/content/zones/ Solaris Zones] and plex can only run x86 OSs on x86 hardware[http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/jail.html FreeBSD Jails] are examples of OS-level virtualization. :)

=== Paravirtualization =Short comparison ==<!--T:6-->This technique also requires a VMMThe three techniques differ in complexity of implementation, but most breadth of its work is performed in the ''guest OS'' codesupport, which performance in turn is ''modified'' to support this VMM comparison with standalone server, and avoid unnecessary use level of privileged instructionsaccess to common resources. The paravirtualization technique also enables running different OSs on a single serverFor example, VMs have wider scope of usage, but poorer performance. Para-VMs have better performance, but requires them can support fewer OSs because one has to be ported, i.e. they should "know" they are running under modify the hypervisor. The paravirtualization approach is used by products such as [http://www.xensource.com/xen/ Xen] and [http://user-mode-linux.sourceforge.net/ UML]original OS.

=== <!--T:7-->Virtualization on the OS level ===Most applications running on a server can easily share a machine with others, if they could be isolated provides the best performance and securedscalability compared to other approaches. Further, in most situations, different operating Performance difference of such systems are not required on the same servercan be as low as 1…3%, merely multiple instances comparing with that of a single ''operating system''. OS-level virtualization systems have been designed to provide the required isolation and security to run multiple applications or copies of the same OS (but different distributions of the OS) on the same standalone server. [http://openvz.org/ OpenVZ[Virtual Environment], [http://linux-vserver.org/ Linux-VServer] s are usually also much simpler to administer as all of them can be accessed and [http://wwwadministered from the host system.sun.com/bigadmin/content/zones/ Solaris Zones] Generally, such systems are examples the best choice for server consolidation of same OS-level virtualizationworkloads.

== Short comparison Where to go further ==<!--T:8-->The three techniques differ in complexity of implementation, breadth of OS support, performance in comparison with standalone server, and level of access If you've decided to common resources. For example, VMs have wider scope of usage, but poor performance. Para-VMs have better performance, but can support fewer OSs because of need try OpenVZ virtualization solution go to modify the original OSs[[Quick installation|OpenVZ installation]] section.

Virtualization on the OS level provides the best performance and scalability compared to other approaches. Performance difference of such systems can be as low as 1…3%, comparing with that of a standalone server. [[Virtual environment]]s are usually also much simpler to administer as all of them can be accessed and administered from the host system. Generally, such systems are the best choice for server consolidation of same OS workloads. == External links ==<!--T:9-->