Difference between revisions of "An Overview of Virtualization Techniques"
(→Guest Operating System Virtualization) |
m (Text replacement - "<htmlet>xen<htmlet>" to "<htmlet>xen</htmlet>") |
||
| (17 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
<table border="0" cellspacing="0" width="100%"> | <table border="0" cellspacing="0" width="100%"> | ||
<tr> | <tr> | ||
| − | <td width="20%">[[About Xen Virtualization Essentials|Previous]]<td align="center">[[Xen Virtualization Essentials|Table of Contents]]<td width="20%" align="right">[[Configuring and | + | <td width="20%">[[About Xen Virtualization Essentials|Previous]]<td align="center">[[Xen Virtualization Essentials|Table of Contents]]<td width="20%" align="right">[[Configuring and Installing a Xen Hardware Virtual Machine (HVM) domainU Guest|Next]]</td> |
<tr> | <tr> | ||
| − | <td width="20%">About Xen Virtualization Essentials<td align="center"><td width="20%" align="right">Configuring and | + | <td width="20%">About Xen Virtualization Essentials<td align="center"><td width="20%" align="right">Configuring and Installing a Xen Hardware Virtual Machine (HVM) domainU Guest</td> |
</table> | </table> | ||
<hr> | <hr> | ||
| − | Throughout this book the word '' | + | <htmlet>xen</htmlet> |
| + | |||
| + | |||
| + | Throughout this book the word ''virtualization'' is used within the context of using Xen technology to run multiple operating systems on a single physical computer system. It is important, however, to appreciate that virtualization is actually a "catch all" term that refers to a variety of different solutions and technologies, of which Xen is only one. | ||
When deciding on the best approach to implementing virtualization it is important to have a clear understanding of the different virtualization solutions which are currently available. The purpose of this chapter, therefore, is to describe in general terms the four virtualization techniques in common use today, namely guest operating system, shared kernel, hypervisor and kernel level. | When deciding on the best approach to implementing virtualization it is important to have a clear understanding of the different virtualization solutions which are currently available. The purpose of this chapter, therefore, is to describe in general terms the four virtualization techniques in common use today, namely guest operating system, shared kernel, hypervisor and kernel level. | ||
| Line 14: | Line 17: | ||
== Guest Operating System Virtualization == | == Guest Operating System Virtualization == | ||
| − | Guest OS virtualization is perhaps the easiest concept to understand. In this scenario the physical host computer system runs a standard unmodified operating system such as Windows, Linux, Unix or MacOS X. Running on this operating system is a virtualization application which executes in much the same way as any other application such as a word processor or spreadsheet would run on the system. It is within this virtualization application that one or more virtual machines are created to run the guest operating systems on the host computer. The virtualization application is responsible for starting, stopping and managing each virtual machine and essentially controlling access to physical hardware resources on behalf of the individual virtual machines. Some examples of guest OS virtualization technologies include | + | Guest OS virtualization is perhaps the easiest concept to understand. In this scenario the physical host computer system runs a standard unmodified operating system such as Windows, Linux, Unix or MacOS X. Running on this operating system is a virtualization application which executes in much the same way as any other application such as a word processor or spreadsheet would run on the system. It is within this virtualization application that one or more virtual machines are created to run the guest operating systems on the host computer. The virtualization application is responsible for starting, stopping and managing each virtual machine and essentially controlling access to physical hardware resources on behalf of the individual virtual machines. The virtualization application also engages in a process known as ''binary rewriting'' which involves scanning the instruction stream of the executing guest system and replacing any privileged instructions with safe emulations. This has the effect of making the guest system think it is running directly on the system hardware, rather than in a virtual machine within an application. |
| + | |||
| + | Some examples of guest OS virtualization technologies include VMware Server and VirtualBox. | ||
The following figure provides an illustration of guest OS based virtualization: | The following figure provides an illustration of guest OS based virtualization: | ||
| Line 26: | Line 31: | ||
== Shared Kernel Virtualization == | == Shared Kernel Virtualization == | ||
| − | Shared kernel virtualization (also known as system level or operating system virtualization) takes advantage of the architectural design of Linux and UNIX based operating systems. In order to understand how shared kernel virtualization works it helps to first understand the two main components of Linux or UNIX operating systems. At the core of the operating system is the ''kernel''. The kernel, in simple terms, handles all the interactions between the operating system and the physical hardware. The second key component is the ''root | + | Shared kernel virtualization (also known as system level or operating system virtualization) takes advantage of the architectural design of Linux and UNIX based operating systems. In order to understand how shared kernel virtualization works it helps to first understand the two main components of Linux or UNIX operating systems. At the core of the operating system is the ''kernel''. The kernel, in simple terms, handles all the interactions between the operating system and the physical hardware. The second key component is the ''root file system'' which contains all the libraries, files and utilities necessary for the operating system to function. Under shared kernel virtualization the virtual guest systems each have their own ''root file system'' but share the kernel of the host operating system. This structure is illustrated in the following architectural diagram: |
| Line 32: | Line 37: | ||
| − | This type of virtualization is made possible by the ability of the kernel to dynamically change the current root | + | This type of virtualization is made possible by the ability of the kernel to dynamically change the current root file system (a concept known as ''chroot'') to a different root file system without having to reboot the entire system. Essentially, shared kernel virtualization is an extension of this capability. Perhaps the biggest single drawback of this form of virtualization is the fact that the guest operating systems must be compatible with the version of the kernel which is being shared. It is not, for example, possible to run Microsoft Windows as a guest on a Linux system using the shared kernel approach. Nor is it possible for a Linux guest system designed for the 2.6 version of the kernel to share a 2.4 version kernel. |
Linux VServer, Solaris Zones and Containers, FreeVPS and OpenVZ are all examples shared kernel virtualization solutions. | Linux VServer, Solaris Zones and Containers, FreeVPS and OpenVZ are all examples shared kernel virtualization solutions. | ||
| Line 38: | Line 43: | ||
== Kernel Level Virtualization == | == Kernel Level Virtualization == | ||
| − | Under kernel level virtualization the host operating system runs on a specially modified kernel which contains extensions designed to manage and control multiple | + | Under kernel level virtualization the host operating system runs on a specially modified kernel which contains extensions designed to manage and control multiple virtual machines each containing a guest operating system. Unlike shared kernel virtualization each guest runs its own kernel, although similar restrictions apply in that the guest operating systems must have been compiled for the same hardware as the kernel in which they are running. Examples of kernel level virtualization technologies include User Mode Linux (UML) and Kernel-based Virtual Machine (KVM). |
The following diagram provides an overview of the kernel level virtualization architecture: | The following diagram provides an overview of the kernel level virtualization architecture: | ||
| Line 44: | Line 49: | ||
[[Image:kernel_level_diagram.jpg|center|Kernel Level Virtualization Diagram]] | [[Image:kernel_level_diagram.jpg|center|Kernel Level Virtualization Diagram]] | ||
| − | |||
== Hypervisor Virtualization == | == Hypervisor Virtualization == | ||
| − | The x86 family of CPUs provide a range of ''protection levels'' also known as ''rings'' in which code can execute. Ring 0 has the highest level privilege and it is this ring | + | The x86 family of CPUs provide a range of ''protection levels'' also known as ''rings'' in which code can execute. Ring 0 has the highest level privilege and it is in this ring that the operating system kernel normally runs. Code executing in ring 0 is said to be running in ''system space'', ''kernel mode'' or ''supervisor mode''. All other code such as applications running on the operating system operates in less privileged rings, typically ring 3. |
| − | Under hypervisor virtualization a program known as a hypervisor runs directly on the hardware of the host system in ring 0. The task of this hypervisor is to handle resource allocation for the virtual machines in addition to administration and monitoring | + | Under hypervisor virtualization a program known as a ''hypervisor'' (also known as a type 1 Virtual Machine Monitor or VMM) runs directly on the hardware of the host system in ring 0. The task of this hypervisor is to handle resource and memory allocation for the virtual machines in addition to providing interfaces for higher level administration and monitoring tools. |
| − | Clearly, with the hypervisor occupying ring 0 of the CPU, the kernels for any guest operating systems running on the system must run in | + | Clearly, with the hypervisor occupying ring 0 of the CPU, the kernels for any guest operating systems running on the system must run in less privileged CPU rings. Unfortunately, most operating system kernels are written explicitly to run in ring 0 for the simple reason that they need to perform tasks that are only available in that ring, such as the ability to execute privileged CPU instructions and directly manipulate memory. A number of different solutions to this problem have been devised in recent years, each of which is described below: |
=== Paravirtualization === | === Paravirtualization === | ||
| − | Under paravirtualization the guest | + | Under paravirtualization the kernel of the guest operating system is modified specifically to run on the hypervisor. This typically involves replacing any privileged operations that will only run in ring 0 of the CPU with calls to the hypervisor (known as ''hypercalls''). The hypervisor in turn performs the task on behalf of the guest kernel. This typically limits support to open source operating systems such as Linux which may be freely altered and proprietary operating systems where the owners have agreed to make the necessary code modifications to target a specific hypervisor. These issues not withstanding, the ability of the guest kernel to communicate directly with the hypervisor results in greater performance levels than other virtualization approaches. |
=== Full Virtualization === | === Full Virtualization === | ||
| − | Full virtualization provides support for unmodified guest operating systems. The term ''unmodified'' refers to operating system kernels which have not | + | Full virtualization provides support for unmodified guest operating systems. The term ''unmodified'' refers to operating system kernels which have not been altered to run on a hypervisor and therefore still execute privileged operations as though running in ring 0 of the CPU. In this scenario, the hypervisor provides CPU emulation to handle and modify privileged and protected CPU operations made by unmodified guest operating system kernels. Unfortunately this emulation process requires both time and system resources to operate resulting in inferior performance levels when compared to those provided by paravirtualization. |
=== Hardware Virtualization === | === Hardware Virtualization === | ||
| − | Hardware virtualization leverages virtualization features built into the latest generations of CPUs from both Intel and AMD. These technologies, known as Intel VT and AMD-V respectively, provide extensions necessary to run unmodified guest virtual machines without the overheads inherent in | + | Hardware virtualization leverages virtualization features built into the latest generations of CPUs from both Intel and AMD. These technologies, known as Intel VT and AMD-V respectively, provide extensions necessary to run unmodified guest virtual machines without the overheads inherent in full virtualization CPU emulation. In very simplistic terms these new processors provide an additional privilege mode above ring 0 in which the hypervisor can operate essentially leaving ring 0 available for unmodified guest operating systems. |
| − | + | ||
| − | In | + | |
The following figure illustrates the hypervisor approach to virtualization: | The following figure illustrates the hypervisor approach to virtualization: | ||
| Line 74: | Line 76: | ||
| − | As outlined in the above illustration, in addition to the virtual machines, an administrative operating system and/or management console also runs on top of the hypervisor allowing the virtual machines to be managed. Hypervisor based virtualization solutions include Xen, VMware ESX Server and Microsoft's Hyper-V technology. | + | As outlined in the above illustration, in addition to the virtual machines, an administrative operating system and/or management console also runs on top of the hypervisor allowing the virtual machines to be managed by a system administrator. Hypervisor based virtualization solutions include Xen, VMware ESX Server and Microsoft's Hyper-V technology. |
| + | |||
| + | |||
| + | <htmlet>xen</htmlet> | ||
Latest revision as of 18:52, 29 May 2016
| Previous | Table of Contents | Next |
| About Xen Virtualization Essentials | Configuring and Installing a Xen Hardware Virtual Machine (HVM) domainU Guest |
| Purchase and download the full PDF and ePub versions of this Xen eBook for only $8.99 |
|
Throughout this book the word virtualization is used within the context of using Xen technology to run multiple operating systems on a single physical computer system. It is important, however, to appreciate that virtualization is actually a "catch all" term that refers to a variety of different solutions and technologies, of which Xen is only one.
When deciding on the best approach to implementing virtualization it is important to have a clear understanding of the different virtualization solutions which are currently available. The purpose of this chapter, therefore, is to describe in general terms the four virtualization techniques in common use today, namely guest operating system, shared kernel, hypervisor and kernel level.
Guest Operating System Virtualization
Guest OS virtualization is perhaps the easiest concept to understand. In this scenario the physical host computer system runs a standard unmodified operating system such as Windows, Linux, Unix or MacOS X. Running on this operating system is a virtualization application which executes in much the same way as any other application such as a word processor or spreadsheet would run on the system. It is within this virtualization application that one or more virtual machines are created to run the guest operating systems on the host computer. The virtualization application is responsible for starting, stopping and managing each virtual machine and essentially controlling access to physical hardware resources on behalf of the individual virtual machines. The virtualization application also engages in a process known as binary rewriting which involves scanning the instruction stream of the executing guest system and replacing any privileged instructions with safe emulations. This has the effect of making the guest system think it is running directly on the system hardware, rather than in a virtual machine within an application.
Some examples of guest OS virtualization technologies include VMware Server and VirtualBox.
The following figure provides an illustration of guest OS based virtualization:
As outlined in the above diagram, the guest operating systems operate in virtual machines within the virtualization application which, in turn, runs on top of the host operating system in the same way as any other application. Clearly, the multiple layers of abstraction between the guest operating systems and the underlying host hardware are not conducive to high levels of virtual machine performance. This technique does, however, have the advantage that no changes are necessary to either host or guest operating systems and no special CPU hardware virtualization support is required.
Shared kernel virtualization (also known as system level or operating system virtualization) takes advantage of the architectural design of Linux and UNIX based operating systems. In order to understand how shared kernel virtualization works it helps to first understand the two main components of Linux or UNIX operating systems. At the core of the operating system is the kernel. The kernel, in simple terms, handles all the interactions between the operating system and the physical hardware. The second key component is the root file system which contains all the libraries, files and utilities necessary for the operating system to function. Under shared kernel virtualization the virtual guest systems each have their own root file system but share the kernel of the host operating system. This structure is illustrated in the following architectural diagram:
This type of virtualization is made possible by the ability of the kernel to dynamically change the current root file system (a concept known as chroot) to a different root file system without having to reboot the entire system. Essentially, shared kernel virtualization is an extension of this capability. Perhaps the biggest single drawback of this form of virtualization is the fact that the guest operating systems must be compatible with the version of the kernel which is being shared. It is not, for example, possible to run Microsoft Windows as a guest on a Linux system using the shared kernel approach. Nor is it possible for a Linux guest system designed for the 2.6 version of the kernel to share a 2.4 version kernel.
Linux VServer, Solaris Zones and Containers, FreeVPS and OpenVZ are all examples shared kernel virtualization solutions.
Kernel Level Virtualization
Under kernel level virtualization the host operating system runs on a specially modified kernel which contains extensions designed to manage and control multiple virtual machines each containing a guest operating system. Unlike shared kernel virtualization each guest runs its own kernel, although similar restrictions apply in that the guest operating systems must have been compiled for the same hardware as the kernel in which they are running. Examples of kernel level virtualization technologies include User Mode Linux (UML) and Kernel-based Virtual Machine (KVM).
The following diagram provides an overview of the kernel level virtualization architecture:
Hypervisor Virtualization
The x86 family of CPUs provide a range of protection levels also known as rings in which code can execute. Ring 0 has the highest level privilege and it is in this ring that the operating system kernel normally runs. Code executing in ring 0 is said to be running in system space, kernel mode or supervisor mode. All other code such as applications running on the operating system operates in less privileged rings, typically ring 3.
Under hypervisor virtualization a program known as a hypervisor (also known as a type 1 Virtual Machine Monitor or VMM) runs directly on the hardware of the host system in ring 0. The task of this hypervisor is to handle resource and memory allocation for the virtual machines in addition to providing interfaces for higher level administration and monitoring tools.
Clearly, with the hypervisor occupying ring 0 of the CPU, the kernels for any guest operating systems running on the system must run in less privileged CPU rings. Unfortunately, most operating system kernels are written explicitly to run in ring 0 for the simple reason that they need to perform tasks that are only available in that ring, such as the ability to execute privileged CPU instructions and directly manipulate memory. A number of different solutions to this problem have been devised in recent years, each of which is described below:
Paravirtualization
Under paravirtualization the kernel of the guest operating system is modified specifically to run on the hypervisor. This typically involves replacing any privileged operations that will only run in ring 0 of the CPU with calls to the hypervisor (known as hypercalls). The hypervisor in turn performs the task on behalf of the guest kernel. This typically limits support to open source operating systems such as Linux which may be freely altered and proprietary operating systems where the owners have agreed to make the necessary code modifications to target a specific hypervisor. These issues not withstanding, the ability of the guest kernel to communicate directly with the hypervisor results in greater performance levels than other virtualization approaches.
Full Virtualization
Full virtualization provides support for unmodified guest operating systems. The term unmodified refers to operating system kernels which have not been altered to run on a hypervisor and therefore still execute privileged operations as though running in ring 0 of the CPU. In this scenario, the hypervisor provides CPU emulation to handle and modify privileged and protected CPU operations made by unmodified guest operating system kernels. Unfortunately this emulation process requires both time and system resources to operate resulting in inferior performance levels when compared to those provided by paravirtualization.
Hardware Virtualization
Hardware virtualization leverages virtualization features built into the latest generations of CPUs from both Intel and AMD. These technologies, known as Intel VT and AMD-V respectively, provide extensions necessary to run unmodified guest virtual machines without the overheads inherent in full virtualization CPU emulation. In very simplistic terms these new processors provide an additional privilege mode above ring 0 in which the hypervisor can operate essentially leaving ring 0 available for unmodified guest operating systems.
The following figure illustrates the hypervisor approach to virtualization:
As outlined in the above illustration, in addition to the virtual machines, an administrative operating system and/or management console also runs on top of the hypervisor allowing the virtual machines to be managed by a system administrator. Hypervisor based virtualization solutions include Xen, VMware ESX Server and Microsoft's Hyper-V technology.
| Purchase and download the full PDF and ePub versions of this Xen eBook for only $8.99 |
|
| Previous | Table of Contents | Next |
| About Xen Virtualization Essentials | Configuring and Installating a Xen Hardware Virtual Machine (HVM) domainU Guest |
