Difference between revisions of "Overview"
From Linux-VServer
(topsort) |
(→External Links: +cat) |
||
| Line 84: | Line 84: | ||
[[Category:Community| ]] | [[Category:Community| ]] | ||
| + | [[Category:Theory| ]] | ||
[[Category:Categories| ]] | [[Category:Categories| ]] | ||
Revision as of 21:59, 21 October 2011
Virtualization is a framework or methodology of dividing the resources of a computer into multiple 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.
Contents |
Types of Virtualization
Some common applications of virtualization are listed below; this list reflects the extreme diversity that the term has come to encapsulate.
Emulation
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 written. 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.
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 systems 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 is a virtualization 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 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 thought of as an advanced extension of the standard chroot mechanism.
The Linux-VServer approach
Abstract
The Linux-VServer technology is a soft 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 full speed, efficiently sharing hardware resources.
A VPS provides an almost identical operating environment as a conventional Linux server. All services, such as ssh, mail, web and database servers can be started on such a VPS, without (or in special cases with only minimal) modification, just like on any real 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.
Introduction
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 Machines (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 emulating some real or fictional hardware, which in turn requires real resources from the Host System (the machine running the VMs). This approach, used by most System Emulators (like QEMU or 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 UML and 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...
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 influence 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 build 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. Ideally, 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 drive ten times the number 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 application 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.
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 distributions, 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 ;-)
History
Jacques Gélinas created the VServer project a number of years back (see 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.
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 possible, but follow the kernel patch development more closely.
In 2005, Benedikt Böhm started another reimplementation of the userspace 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.
