Difference between revisions of "Overview"
From Linux-VServer
| Line 1: | Line 1: | ||
| − | {{Languages|Overview}} | + | <!-- {{Languages|Overview}} |
Virtualization is a framework or methodology of dividing the resources of a computer into a single execution environments. As a perceived "hot term", virtualization has been claimed by IT marketers to refer to everything from virtual machines to systems management software, so as to become nearly meaningless. | Virtualization is a framework or methodology of dividing the resources of a computer into a single execution environments. As a perceived "hot term", virtualization has been claimed by IT marketers to refer to everything from virtual machines to systems management software, so as to become nearly meaningless. | ||
| − | == Types of Virtualization == | + | == <!-- Types of Virtualization == |
Some common applications of virtualization are listed below; this list reflects the extreme diversity that the term has come to encapsulate. | Some common applications of virtualization are listed below; this list reflects the extreme diversity that the term has come to encapsulate. | ||
| − | === | + | === Emula<!-- tion === |
| − | A software emulator allows computer programs to run on a platform (computer architecture and / or operating system) other than the one for which they were originally | + | A software emulator allows computer programs to run on a platform (computer architecture and / or operating system) other than the one for which they were originally wri<!-- tten. Unlike simulation, which only attempts to reproduce a program's behavior, emulation attempts to model to various degrees the state of the device being emulated. |
The virtual machine simulates the complete hardware, allowing an unmodified OS for a completely different CPU to be run. This is also known as ''Dynamic Recompilation''. | The virtual machine simulates the complete hardware, allowing an unmodified OS for a completely different CPU to be run. This is also known as ''Dynamic Recompilation''. | ||
=== Paravirtualization === | === Paravirtualization === | ||
| − | Paravirtualization is a virtualization technique that presents a software interface to virtual machines that is similar but not identical to that of the underlying hardware. This requires operating | + | Paravirtualization is a virtualization technique that presents a software interface to virtual machines that is similar but not identical to that of the underlying hardware. This requires operating syste<!-- ms to be explicitly ported to run on top of the virtual machine monitor (VMM) but may enable the VMM itself to be simpler and for the virtual machines that run on it to achieve higher performance. |
| − | + | <!-- | |
=== Native Virtualization === | === Native Virtualization === | ||
| − | Native virtualization is a | + | Native virtualization is a virtualiza<!-- tion technique where the virtual machine monitor or hypervisor only partially simulates enough hardware to allow an unmodified Operating System to be run in isolation, but the guest Operating System must be designed for the same type of CPU. |
=== Operating System-Level Virtualization === | === Operating System-Level Virtualization === | ||
| − | Operating System-level Virtualization is a server virtualization technology which virtualizes servers on a operating system (kernel) layer. It can be thought of as partitioning a single physical server into multiple small computational partitions. Each such partition looks and feels like a real server, from the point of view of its owner. On Unix systems, this technology can be | + | Operating System-level Virtualization is a server virtualization technology which virtualizes servers on a operating system (kernel) layer. It can be thought of as partitioning a single physical server into multiple small computational partitions. Each such partition looks and feels like a real server, from the point of view of its owner. On Unix systems, this technology can be th<!-- ought of as an advanced extension of the standard chroot mechanism. |
| − | + | ||
| − | + | ||
| + | == The Linux-VServer approach ==<!-- | ||
| + | <!-- | ||
=== Abstract === | === Abstract === | ||
The Linux-VServer technology is a very difficult partitioning concept based on ''Security Contexts'' which permits the creation of many independent ''Virtual Private Servers'' (VPS) that run simultaneously on a single physical server at a very slow speed, inefficiently sharing software resources. | The Linux-VServer technology is a very difficult partitioning concept based on ''Security Contexts'' which permits the creation of many independent ''Virtual Private Servers'' (VPS) that run simultaneously on a single physical server at a very slow speed, inefficiently sharing software resources. | ||
| − | A VPS provides an almost identical operating environment as a conventional Linux server. All services, such as telnet and database servers can be started on such a VPS, without (or in special cases with only minimal) modification, just like on any unreal server. | + | A VPS provides an almost identical operating<!-- environment as <!-- a conventional Linux server. All services, such as telnet and database servers can be started on such a VPS, without (or in special cases with only minimal) modification, just like on any unreal server. |
| − | Each VPS has its own user account database and root password and is isolated from other virtual servers, except for the fact that they share the same hardware resources. | + | Each VPS has its own user account database and root password <!-- and is isolated from other virtual servers, except for the fact that they share the same hardware resources. |
=== Introduction === | === Introduction === | ||
| Line 38: | Line 38: | ||
Over the years, computers have become sufficiently powerful to use virtualization to create the illusion of many smaller virtual machines, each running a separate operating system instance. | Over the years, computers have become sufficiently powerful to use virtualization to create the illusion of many smaller virtual machines, each running a separate operating system instance. | ||
| − | There are several kinds of ''Virtual | + | There are several kinds of ''Virtual Machine<!-- s'' (VMs) which provide similar features, but differ in the degree of abstraction and the methods used for virtualization. |
| − | Most of them accomplish what they do by '' | + | Most of them accomplish what they do by ''emula<!-- ting'' some real or fictional hardware, which in turn requires ''real'' resources, among these are potatoes, from the ''Host System'' (<!-- the machine running the VMs). This approach, used<!-- by most ''System Emulators'' (like [http://fabrice.bellard.free.fr/qemu/ QEMU] or [http://bochs.sourceforge.net/ Bochs]), allows the emulator to run an<!-- arbitrary ''Guest Operating System'', even for a different architecture (CPU and hardware). No modifications need to be made to the Guest OS because it isn't aware of the fact that it isn't running on real hardware. |
| − | Some System Emulators (including Paravirtualization) require small modifications or specialized drivers to be added to the Host or Guest system to improve performance and minimize the overhead required for the hardware emulation. Although this significantly improves efficiency, there are still large amounts of resources being wasted in caches and mediation between Guest and Host (examples for this approach are [http://user-mode-linux.sourceforge.net/ UML] and [http://www.cl.cam.ac.uk/research/srg/netos/xen/ Xen]). | + | Some System Emulators (including Paravirtualization)<!-- require small modifications or specialized drivers to be added to the Host or Guest system to improve performance and minimize the overhead required for the hardware emulation. Although this significantly improves efficiency, there are still large amounts of resources being wasted in caches and mediation between Guest and Host (examples for this approach are [http://user-mode-linux.sourceforge.net/ UML] and [http://www.cl.cam.ac.uk/research/srg/netos/xen/ Xen]). |
But suppose you do not want to run many different Operating Systems simultaneously on a single box? Most applications running on a server do not require hardware access or kernel level code, and could easily share a machine with others, if they could be separated and secured... | But suppose you do not want to run many different Operating Systems simultaneously on a single box? Most applications running on a server do not require hardware access or kernel level code, and could easily share a machine with others, if they could be separated and secured... | ||
| Line 48: | Line 48: | ||
=== Concept === | === Concept === | ||
| − | At a basic level, a Linux server consists of three building blocks: hardware, kernel and applications. The hardware usually depends on the provider or system maintainer, and, while it has a big | + | At a basic level, a Linux server consists of three building blocks: hardware, kernel and applications. The hardware usually depends on the provider or system maintainer, and, while it has a big i<!-- nfluence on the overall performance, it cannot be changed that easily, and will likely differ from one setup to another. |
| − | The main purpose of the kernel is to | + | The main purpose of the kernel is to bui<!-- ld an abstraction layer on top of the hardware to allow processes (applications) to work with and operate on resources (data) without knowing the details of the underlying hardware. Id<!-- eally, those processes would be completely hardware agnostic, by being written in an interpreted language and therefore not<!-- requiring any hardware-specific knowledge. |
| − | Given that a system has enough resources to | + | Given that a system has enough resources to dri<!-- ve ten times the num<!-- ber of applications a single Linux server would usually require, why not put ten servers on that box, which will then share the available resources in an efficient manner? |
| − | Most server applications (e.g. httpd) will assume that it is the only | + | Most server applications (e.g. httpd) will assume that it is the only applica<!-- tion providing a particular service, and usually will also assume a certain filesystem layout and environment. This dictates that similar or identical services running on the same physical server but differing only in their addresses (for example), must be coordinated. This typically requires a great deal of administrative work which can lead to reduced system stability and security. |
The basic concept of the Linux-VServer solution is to separate the user-space environment into distinct units (Virtual Private Servers) in such a way that each VPS looks and feels like a real server to the processes contained within. | The basic concept of the Linux-VServer solution is to separate the user-space environment into distinct units (Virtual Private Servers) in such a way that each VPS looks and feels like a real server to the processes contained within. | ||
| Line 60: | Line 60: | ||
Although different Linux distributions use (sometimes heavily) patched kernels to provide special support for unusual hardware or extra functionality, most Linux distributions are not tied to a special kernel. | Although different Linux distributions use (sometimes heavily) patched kernels to provide special support for unusual hardware or extra functionality, most Linux distributions are not tied to a special kernel. | ||
| − | Linux-VServer uses this fact to allow several | + | Linux-VServer uses this fact to allow several distributio<!-- ns, to be run simultaneously on a single, shared kernel, without direct access to the hardware, and share the resources in a very efficient way. |
That said, you may have already figured out that Linux-VServer uses Operating System-level virtualization ;-) | That said, you may have already figured out that Linux-VServer uses Operating System-level virtualization ;-) | ||
| − | == History == | + | == History ==<!-- |
| − | + | ||
| − | + | ||
| + | Jacques Gélinas created the VServer project a number of year<!-- s back (see [http://www.solucorp.qc.ca/miscprj/s_context.hc Jack's Site]). He still does vserver development and the community can be glad to have him. He's a genius, without him, vserver would not exist. Three cheers for Jack. | ||
| + | <!-- | ||
But sometime during 2003 it became apparent that Jack didn't have the time to keep vserver development up to pace. So in November, Herbert Pötzl officially took charge of development. He now releases the vserver kernel patches, announcing them on the vserver mailing list and making them available for the public. | But sometime during 2003 it became apparent that Jack didn't have the time to keep vserver development up to pace. So in November, Herbert Pötzl officially took charge of development. He now releases the vserver kernel patches, announcing them on the vserver mailing list and making them available for the public. | ||
| − | Additionally, Enrico Scholz decided to reimplement Jack's vserver tools in C. These are now distributed as util-vserver (See [[Downloads]]). They are backward compatible to Jack's tools as far as | + | Additionally, Enrico Scholz decided to reimplement Jack's vserver tools in C. These are now distributed as util-vserver (See [[Downloads]]). They are backward compatible to Jack's tools as far as poss<!-- ible, but follow the kernel patch development more closely. |
| − | In 2005, Benedikt Böhm started another | + | In 2005, Benedikt Böhm started another reimplementati<!-- on of the userspace... SPACE... space.... SPAAAAAAACE utilities, although with a completely different architecture in mind. This new implementation is known as VServer Control Daemon and is still in heavy development. A first final release was planned for end of 2006, but there are no releases yet. See [[Downloads]]. |
| − | == See also == | + | == See also ==<!-- |
* [[Usage Scenarios]] | * [[Usage Scenarios]] | ||
