Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! () Begründung: Aus Einleitung und Inhalt ist schwer verständlich, was Hypervisor wirklich ist. "Ein Computerprogramm" ist hier ein nichtssagender Allgemeinbegriff, da er nicht weiter erläutert wird. Ist das ein Oberbegriff (dann fehlen Beispiele oder Kategorien), oder ist es das einzige Programm (von welchem Hersteller)? Der Artikel ist entsprechend schlecht belegt ohne Literatur oder Weblinks und wirkt wie eine Kurzversion des englischen Artikels ohne hinreichende Überarbeitung.

Hypervisor, auch Virtual Machine Monitor (kurz VMM) genannt, ist die Bezeichnung für eine Klasse von Systemen der praktischen Informatik, die als abstrahierende Schicht zwischen tatsächlich vorhandener Hardware (und ggf. auf dem System bereits installiertem Betriebssystem) und weiteren zu installierenden Betriebssystemen dient. Solche Systeme erlauben es eine virtuelle Umgebung (Hardwareressourcen, insbes. CPU, Speicher, Festplattenplatz, verfügbare Periepherie) zu definieren die unabhängig von der tatsächlich vorhandenen Hardware als Basis für die Installation von (Gast-)Betriebssystemen dient.

Hypervisoren erlauben den Betrieb mehrerer Gastsysteme auf einem Hostsystem. Der Hypervisor verwaltet die Ressourcenzuteilung für einzelne Gastsysteme. Er verteilt die Hardware-Ressourcen derart, dass für jedes einzelne Gastbetriebssystem alle Ressourcen bei Bedarf verfügbar sind, so, als ob nur ein Betriebssystem vorhanden wäre. Dies kann durch Hardware-Emulation, Hardware-Virtualisierung oder Paravirtualisierung stattfinden. Den einzelnen Gastsystemen wird dabei jeweils ein eigener kompletter Rechner mit allen Hardware-Elementen (Prozessor, Laufwerke, Arbeitsspeicher, usw.) vorgespielt.

Die tatsächlich vorhanden Hardwareumgebung (ggf. inklusive installiertem Betriebssystem - das dann als Hostbetriebssystem bezeichnet wird) wird als Hostsystem bezeichnet.

Die virtuelle Umgebung (oft auch als Virtuelle Maschine oder Gastsystem bezeichet) mit dem installierten Gastbetriebssystem ist auf allen Hostsystemen lauffähig, auf denen der Hypervisor installiert bzw. lauffähig ist. Es spielt dabei aus Sicht des Gastsystems keine Rolle, auf welcher Hardwareumgebung der Hypervisor selbst installiert ist, da der Hypervisor von der tatsächliche vorhandenen Hardware abstrahiert.

In ihrem Artikel "Formal Requirements for Virtualizable Third Generation Architectures" von 1974 legten Gerald J. Popek and Robert P. Goldberg die formalen Grundlagen und stellen die Grundlegenden Anforderungen an eine Architektur dar, um Hypervisor zu unterstützen.^[1]

„Hyper“ stammt aus dem Griechischen und bedeutet „über“. „Visor“ lässt sich aus dem Lateinischen „videre“ ableiten, was „sehen“ bedeutet. Sinngemäß übersetzt handelt es sich also um ein System, welches als „Aufseher“ etwas bzw. weitere Systeme „überblickt“ bzw. „etwas überwacht“.

Eine in Fachartikeln und einschlägiger Literatur häufig anzutreffen Klassifizierung unterscheidet zwei Typen von Hypervisoren^[2]<:

• Ein Typ-1-Hypervisor (native oder bare-metal) setzt direkt auf der Hardware auf und benötigen keine vorherige Betriebssystem-Installation. Das setzt allerdings voraus das die Hardware des Hostsystem vom Typ-1-Hypervisor durch entsprechende Treiber unterstüzt wird.
• Ein Typ-2-Hypervisor (hosted) setzt auf einem vollwertigen Betriebssystem auf dem Hostsystem auf und nutzt die Gerätetreiber des Betriebssystems, um auf die Hardware des Hostsystem zuzugreifen. Typ-2-Hypervisor sind daher auf allen Hostystemen lauffähig auf denen vom Hypervisor unterstützte Hostbetriebssysteme lauffähig sind.

Der Begriff Hypervisor wird in Veröffentlichungen und in der Presse zum Teil uneinheitlich verwendet, da er in einigen Quellen auf Typ 1^[3] oder auf Typ 2 mit Paravirtualisierung beschränkt wird. Quellen von IBM verwenden den Begriff Hypervisor allgemein, also für Typ 1 und Typ 2.^[4]. Auch Quellen von VMWare sprechen von Bare-Metal-Hypervisor (Typ-1) um sie von Typ-2 Hypervisoren zu unterscheiden und verwenden den Begriff Hypervisor damit für Kategorie Typ-1 wie auch Typ-2.^[5]

Die ersten Hypervisoren die Virtualisierung ermöglichten waren das von IBM entwickelte Testwerkzeug SIMMON auf Basis der damals neuen System/360 Hardware sowie das Forschungsystem CP-40, das in der ersten Version 1967 fertiggestellt wurde und später zur ersten Version von IBM's CP/CMS- Betriebssystem mit der Bezeichnung CP-40/CMS weiterentwickelt wurde. CP-40/CMS lief ebenfalls auf der System/360 Hardware, die so modifiziert wurde, dass zum ersten Mal eine Implementierung der virtuellen Speicherverwaltung verfügbar war. Vor 1967 war Virtualisierung in einigen Betriebssystemen nur in dem Sinne implementiert, das mehrere Anwendungsprogramme zeitgleich ausgeführt werden konnten (zum Beispiel CTSS und IBM M44/44X) und sich die gleiche Hardware (transparent für die Anwendungsprogramme) teilten. Mit CP-40/CMS war es zum ersten Mal möglich mehrere Betriebssysteme in separaten virtuellen Maschinen zu betreiben.

Für das IBM System/360-67 wurde CP-40 komplett reimplementiert und als CP-67 zum Ersten auch kommerziell verfügbaren Produktionssystem mit implementierter Komplett-Virtualisierung. Die erste Auslieferung der Hardware erfolgte 1967 - sie enthielt bereits Features wie in Hardware implementierte Page Translation Tables für virtuellen Speicher und andere Techniken die es erlaubten Kernel Tasks, I/O- und Interrupt Handling zu virtualisieren. Im gleichen Jahr wurde CP-40 und CP-60 auf ersten Großrechnern eingesetzt. Von 1968 bis 1972 stellt IBM seinen Kunden den Source Code von CP/CMS ohne Support zur Verfügung.

CP/CMS war Teil von IBM's Anstregungen ein robustes time-sharing System für seine Großrechner bereitzustellen. Da durch den Hypervisor mehrere Betriebssysteme parallel ausgeführt werden konnten, erhöhter er Zuverlässigkeit und Robustheit: Selbst wenn ein Betriebssystem ausfiel konnten die anderen Betriebssysteme unbeeinflußt weiterarbeiten. Es erlaubte ausserdem den parallelen Betrieb unterschiedlicher (zum Teil experimenteller) Versionen der Betriebssysteme.

IBM kündigt das System/370 als Nachfolger der System/360-Serie 1970 ohne Virtualisierungsunterstützung an, fügte diese Funktionalität jedoch 1972 hinzu. Seitdem ist Virtualisierung ein Bestandteil aller Nachfolger-Systeme (alle modernen Systeme, wie das System z sind voll rückwärtskompatible zu den Serie-S/360 Großrechner der 1960'er Jahre.) Die Ankündigung der Unterstützung der Virtualisierung 1972 enthielt auch die Anküdigung des VM/370-Betriebssystems, einer Reimplementierung des CP/CMS-Systems für die S/370-Serie. Im Unterschied zu CP/CMS bot IBM Software-Support für diese Version, obwohl die Auslieferung lang Zeit immer noch in Form von Sourcecode erfolgte. Das Kürzel 'VM' stand für Virtual Machine - man wollte damit betonen, dass nun alle - nicht nur einige Hardware-Interfaces virtualisiert waren. Sowohl VM als auch CP/CMS erfreuten sich großer Akzeptanz seitens Universitäten, Forschungseinrichtungen, Geschäftkundenanwendern und innerhalb IBM selbst. Trotzdem verloren VM bzw. CP/CMS nach einer Reihe von heftigen Disputen und Diskussionen innerhalb von IBM zwischen "time-sharing" Anhängern und "batch processing" Anhängern gegenüber dem batch gestützten MVS-Betriebssytem an Boden - schließlich wurde VM für Jahrzehnte als IBM's "anderes" Betriebssystem neben MVS angesehen. Nach dem Jahr 2000 gewann VM wieder stärker an Bedeutung, da es in Form von z/VM unter Anderem als Plattform für "Linux for zSeries" diente.

Die großen Unixhersteller, insbesondere Sun Microsysteme, HP, IBM and SGI verkaufen Serverlösung mit Virtualisierungsunterstützung bereits seit Ende der 1990'er Jahre. Diese Lösungen waren meist nur mit sehr großen und entsprechend teuren Systemen erhältlich. Es gab aber auch einige im mittleren Preissegment angesiedelte Lösungen, wie z.B. IBM's pSeries Server, Sun/Oracles's CoolThreads Server und HP's Superdome Server.

Mehrere Einflussfaktoren führten ab 2005 zu einem Wiederaufleben der Bemühungen um die Virtualisierungstechnologien unter den Unix- und Linux-Serverherstellern:^[6]

• Leistungsfähigere Hardware erlaubt es jeder einzelnen Maschine mehr Dinge parallel zu bearbeiten
• Anstrengungen das Servermanagement und die Konsolidierung vorhandener Server zu vereinfachen
• Notwendigkeit große Multiprozessor- and Servercluster-Installationen - zum Beispiel in Server- und Render Farmen - zu verwalten
• Verbesserung von Sicherheit, Zuverlässigkeit und größere hardwareunabhängigkeit durch Hypervisor Installationen
• Die Möglichkeit komplexe, betriebssystemabhängige Applikationen auf verschiedenen Hardwareplattformen und Betriebssystemen zu betreiben

In den folgenden Abschnitten sind die durch die großen Serverhersteller angebotenen Hypercisor-Technologien dargestellt:

Obwohl Solaris immer das einzige offiziell durch Sun/Oracle unterstützte Gastsystem auf ihrem Logical Domains Hypervisor war, stehen seit Ende 2006 Portierungen von Linux (Ubuntu and Gentoo) und FreeBSD zur Verfügung, die ebenfalls auf dem Sun/Oracle's Logical Domains Hypervisor lauffähig sind. Auch Wind River "Carrier Grade Linux" läuft auf Sun's Hypervisor.^[7] Volle Virutalisierung auf Basis der SPARC Prozessoren erwies sich als relativ einfach: Seit seiner Einführung Mitte der 80'er Jahre hatte Sun bewußt darauf geachtet die Architektur frei von Artefakten zu halten, die der Virtualisierung entgegengestanden hätten.^[8]

Sun's Logical Domains Hypervisor ist ein Typ-1-Hypervisor, da er direkt auf der Hardware ausgeführt wird und er die Ausführung der Gastsysteme steuert/überwacht.

HP nennt seine Technologie um mehrere Gastsysteme auf seinen Itanium-Prozessor basierenden Systemen zu betreiben "Integrity Virtual Machines" (Integrity VM). Die Itanium-Plattform unterstützt HP-UX, Linux, Windows und OpenVMS als Gastbetriebssysteme. Das HP-eigene HP-UX Betriebssystem ist jedoch am Besten auf die "Integrity VM" abgestimmt und bietet Virtualisierungsunterstütztung mit Features wie Prozessor- und Speicher-Hotswaps (d.h. Austausch von Prozessoren oder Speicher im laufenden Betrieb) sowie Kernel-Updates ohne Reboot, die den anderen Betriebssystemen vorenthalten bleiben.

Der Integrity VM Hypervisor ist im Sinne der (Typ-1, Typ-2) Klassifizierung eine Hybridform. Der Integrity VM Hypervisor basiert im Wesentlichen auf HP-UX und läuft direkt auf der Hardware im Sinne eines Typ-1-Hypervisors. Die Gastbetriebssysteme laufen parallel zum Integrity VM Hypervisor, der als Spezialform des HP-UX OS gleichzeitig auch prinzipiell die Ausführung von HP-UX Anwendungen zulassen würde (auch wenn dies durch HP nicht empfohlen wird). Aus diesem Grund kann hier nicht von einem reinen Typ-1-Hypervisor sondern nur von einer Hybridform gesprochen werden.

IBM bietet Virtualisierungsunterstützung durch eine Logical Partitioning (LPAR) genannte Technologie auf den Plattformen System/390, zSeries, pSeries and iSeries. Der von IBM "PowerVM" genannte Hypervisor arbeitet auf allen genannten Plattformen als in der Firmware implementierter bare-metal (Typ-1) Hypervisor, der Isolation zwischen den logischen Partitionen (LAPRs) gewährleistet. Prozessor Kapazität wird den LPARs entweder explizit zugeteilt oder es auf Basis frei verfügbarer CPU-Kapazität dynamisch Kapazitäte zugeteilt, wo sie wegen hoher Last gerade am Dringensten benötigt werden. LPAR Gruppen können gemeinsame CPU Kapazität in Form eines Pools verwalten lassen - IBM bezeichnet dieses Feature als Multiple Shared-Processor Pools (MSPPs) und stellt es in Server mit dem POWER6-Prozessor zur Verfügung. LPAR und MSPP Kapazitätszuweisungen können dynamisch angepasst werden. Speicher wird jedem LPAR entweder initial definiert beim Start oder dynamisch und wird bezügl. des Adressraums von der PowerVM kontrolliert (zum Schutz der Adressräume der unterschiedlichen VM's). I/O Adapter können entweder exklusiv einem LPAR "gehören" oder zwischen LPARs über einen Mechanismus mit der Bezeichnung Virtual I/O Server (VIOS) geteilt werden. Der Power Hypervisor sorgt durch Hotswap-Features für Prozessoren, Speicher, I/O-Adapter, Ventilatoren, Festplatten, Controller, etc. (welche Features genau unterstützt werden hängt vom genauen Modell ab) für hohe Ausfallsicherheit, kurze Wartungsfenster and hohe Verfügbarkeit.

Dieser Artikel oder Abschnitt bedarf einer grundsätzlichen Überarbeitung. Näheres sollte auf der Diskussionsseite angegeben sein. Bitte hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Beginnend mit dem Jahre 2005 haben die CPU-Hersteller im x86-Bereich begonnen Virtualisierungsunterstützung in ihre Produkte zu integrieren: Beispielsweise haben Intel-Prozessoren Intel VT-x (codenamed Vanderpool) unt Intel APICv zur Interrupt-Virtualisierung integriert, AMD-Prozessoren AMD-V (codenamed Pacifica) und AMD AVIC zur Interrupt-Virtualisierung und VIA-Prozessoren VIA VT integriert. Virtualisierungssoftware die diese Prozessorerweiterungen Ausnutzen sind z.B. VirtualBox, Windows Virtual PC, VMware Workstation, Parallels Desktop for Mac, Xen, VMware ESX/ESXi, KVM und Hyper-V

Bei Hyper-V (Codename "Viridian" - früher auch "Windows Server Virtualization") handelt es sich um einen von Microsoft erstmal 2008 ausgelieferten Typ-1-Hypervisor; ^[9]Windows Versionen ab Windows Vista enthalten Erweiterungen um die Performance zu Optimieren, wenn sie basieremd auf Hyper-V betrieben werden.

Bei VMware ESX/ESXi handelt es sich um einen Typ-1-Hypervisor.

Bei VirtualBox, Windows Virtual PC, VMware Workstation, Parallels Desktop for Mac und Xen handelt es sich um Typ-2-Hypervisor, die ein Basisbetriebssystem zur Installation benötigen.

Da Embedded Systeme häufig nur stark beschränkte Ressourcen zur Verfügung haben (insbesondere batteriegetriebene, mobile oder kartenintegrierte "on-chip" System) sind wichtige Anforderungen an Hypervisoren im Embedded-Bereich insbesondere geringer Speicherplatzverbrauch und geringer Verwaltungsaufwand in Form von zusätzlicher CPU-Rechenzeit. Hypervisoren für Embedded Echtzeitbetriebssysteme (RTOS) als Sonderform von Embedded Systeme müssen zusätzlich bereits unter Berücksichtigung von strengen real-time Anforderungen entworfen werden.

Schließlich existieren in der Welt der Embedded Systeme noch mehr konkurrierende Architekturen als in der Vergleichsweise überschaubaren Welt der x86 Architekturen der PC-Welt. Unterstützung für Virtualisiserung durch das Betriebssystem erfordert aber mindestens Speicherschutzmechanismen in Forms einer Memory Management Unit oder zumindest einer einfachen Speicherschutzeinheit und eine Unterscheidung zwischen einem priviligierten und einem Benutzermodus auf Betriebssystemebene.^[2] Diese Anforderungen schließen die Umsetzung der Virtualisierung auf vielen Embedded Plattformen bereits aus. Die o.g. Features werden aber mindesten von x86-, MIPS-, ARM- und PowerPC-Architekturen als weitverbreitetenen Architekturen im Embedded Umfeld unterstützt^[10]

Da Hersteller von Embedded Systemen normalerweise auch ihr eigenes Betriebssystem mit dem Chip mitliefern und damit volle Hoheit über Betriebssystemänderungen haben, besteht weniger Bedarf für volle Virtualisierung als im PC-Bereich (in dem es eine klare Trennung zwischen Hardware- und Betriebssystemherstellern gibt). Stattdessen machen Performancevorteile der Paravirtualisierung diese häufig zur Technologie der Wahl im Embedded Bereich. ARM bietet mit dem ARM Cortex A15 aber auch einen high-end Embedded Prozessor mit Unterstützung für volle Hardware-Virtualisierung an.

Weitere Unterschiede zwischen der Virtualisierung im Server/Desktop-Bereich und Embedded Umgebungen liegen in Anforderungen bezgl. effizientem Sharing von Resourcen zwischen Virtuellen Maschinen, inter-VM Kommunikation mit hoher Bandbreite und geringer Latency sowie feingranularer Kontrolle des Informationsflusses zwischen VM's.^[11]

Dieser Artikel oder Abschnitt bedarf einer grundsätzlichen Überarbeitung. Näheres sollte auf der Diskussionsseite angegeben sein. Bitte hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Es können für die Entwicklung von Software unterschiedliche Komponenten vorgehalten werden. So kann zum Beispiel eine Datenbankabstraktionsschicht mit Oracle und SQL-Server getestet werden, ohne beide gleichzeitig installieren zu müssen.

Ein großer Vorteil ist die einfache Möglichkeit, die VMs weiterzugeben. Das Kopieren der Dateien genügt, da diese auf jedem Rechner lauffähig sind. Somit kann in einer Abteilung für technischen Support die Software in unterschiedlichen Versionen vorgehalten werden.

Durch PC-Virtualisierungsoftware ist es unter anderem auch möglich, Computerspiele zu spielen, die z. B. im Kompatibilitätsmodus von Windows XP nicht einwandfrei funktionieren. Einige ältere Spiele laufen zwar im Kompatibilitätsmodus und man kann auch Spielstände speichern, das Laden dieser Spielstände kann jedoch bei verschiedenen Spielen zum Computerabsturz führen.

1. ↑ Gerald J. Popek and Robert P. Goldberg: Formal Requirements for Virtualizable Third Generation Architectures. In: Communications of the ACM. 17. Jahrgang, Nr. 7, 1974, S. 412–421, doi:10.1145/361011.361073 (acm.org). 
2. ↑ ^{a b} Will Keegan: The Rise of the Type Zero Hypervisor. In: Intel Embedded Innovator. Intel, 2012, abgerufen am 27. Juli 2014: „The Type Zero hypervisor is a new concept that is even smaller than Type 1. Type Zero is a bare-metal architecture that removes the need for a support OS. By shedding the support OS, the Type Zero hypervisor drastically reduces the size and computational overhead imposed on virtualization platforms.“ 
3. ↑ Computerwoche - Alles über Virtualisierung - abgerufen am 16. August 2014
4. ↑ IBM Systems Virtualization, IBM Corporation, Version 2 Release 1 (2005), available on-line at publib.boulder.ibm.com (PDF-Datei; 247 kB) – description of basic concepts
5. ↑ vSphere Hypervisor
6. ↑ (virtualization quickly becoming open source 'killer app')
7. ↑ Wind River To Support Sun's Breakthrough UltraSPARC T1 Multithreaded Next-Generation Processor
8. ↑ Wind River To Support Sun's Breakthrough UltraSPARC T1 Multithreaded Next-Generation Processor
9. ↑ Peter Galli. "Microsoft Sheds More Light on Windows Hypervisor Technology." April 5, 2006.
10. ↑ Marius Strobl: Virtualization for Reliable Embedded Systems. GRIN Publishing GmbH, Munich 2013, ISBN 978-3-656-49071-5, S. 5–6 (grin.com). 
11. ↑ Gernot Heiser: The role of virtualization in embedded systems. April 2008, S. 11–16 (com.au). Fehler bei Vorlage * Parametername unbekannt (Vorlage:Cite conference): "booktitle"