Hypervisor, auch Virtual-Machine-Monitor (aus englisch , kurz VMM) genannt, ist eine Software oder Firmware, die virtuelle Maschinen erstellt und verwaltet. Die Funktion in modernen Computern erlaubt es eine virtuelle Umgebung (Hardwareressourcen, insbesondere CPU, Speicher, Festplattenspeicherplatz und verfügbare Peripherie) zu definieren, welche dann unabhängig von der tatsächlich vorhandenen Hardware als Basis für die Installation von (Gast-)Betriebssystemen dient. Dies geschieht, indem eine abstrahierende Schicht zwischen tatsächlich vorhandener Hardware (und ggf. auf dem System bereits installiertem Betriebssystem) und weiteren zu installierenden Betriebssystemen bereitgestellt wird.
Einige Literatur, insbesondere im Mikrokern-Kontext, macht eine Unterscheidung zwischen Hypervisor und Virtual-Machine-Monitor (VMM). Dort bilden beide Komponenten den Virtualisierungs-Stack eines bestimmten Computersystems. Hypervisor bezieht sich auf Kernel-Space-Funktionalität und VMM auf User-Space-Funktionalität. Insbesondere in diesen Kontexten ist ein Hypervisor ein Mikrokern, der Virtualisierungsinfrastruktur implementiert, die aus technischen Gründen im Kern laufen muss, wie beispielsweise Intel VMX. Mikrokerne, die Virtualisierungsmechanismen implementieren, werden auch Microhypervisor genannt. Wenn man diese Terminologie auf Linux anwendet, dann ist KVM ein Hypervisor und QEMU oder auch Cloud Hypervisor sind VMMs, die KVM als Hypervisor nutzen.
Eigenschaften Hypervisoren erlauben den simultanen 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 vorhandene Hardwareumgebung wird als Hostsystem bezeichnet. Das ggf. darauf installierte Betriebssystem wird als Hostbetriebssystem bezeichnet.
Die virtuelle Umgebung mit dem installierten Gastbetriebssystem (oft auch als Virtuelle Maschine oder Gastsystem bezeichnet) 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ächlich vorhandenen Hardware abstrahiert. Es ist die Aufgabe des Hypervisors, die Ressourcen der Hardware bedarfsgerecht an die virtuellen Maschinen zu verteilen.
In ihrem Artikel „Formal Requirements for Virtualizable Third Generation Architectures“ von 1974 legten Gerald J. Popek und Robert P. Goldberg die formalen Grundlagen und stellen die grundlegenden Anforderungen an eine Architektur dar, um Hypervisoren zu unterstützen.
Hypervisoren können, wenn die Voraussetzungen wie im o. g. Artikel durch die Hardware erfüllt werden, vollständig softwarebasiert umgesetzt werden, d. h., es sind grundsätzlich keine virtualisierungsspezifischen Erweiterungen im Prozessor erforderlich. Da sich durch Erweiterungen im Prozessor (Befehlssatz) jedoch sowohl Geschwindigkeits- als auch Sicherheitsvorteile erzielen lassen, bieten viele Prozessorarchitekturen hardwareseitig implementiert Befehlserweiterungen für die Virtualisierung an.
Wortherkunft „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“.
Klassifizierung mini|hochkant=1.3|Typ-1-Hypervisor mini|hochkant=1.3|Typ-2-Hypervisor
In seiner Doktorarbeit „Architectural Principles for Virtual Computer Systems“ von 1973 unterscheidet R. Goldberg zwei Typen von Hypervisoren: Ein Typ-1-Hypervisor (native oder bare-metal) setzt direkt auf der Hardware auf und benötigt keine vorherige Betriebssystem-Installation. Das setzt allerdings voraus, dass die Hardware des Hostsystems vom Typ-1-Hypervisor durch entsprechende Treiber unterstützt 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 Hostsystems zuzugreifen. Typ-2-Hypervisoren sind daher auf allen Hostsystemen 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 1Alles über Virtualisierung. In: Computerwoche, abgerufen am 16. August 2014. 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.IBM Systems Virtualization, IBM Corporation, Version 2 Release 1 (2005), available on-line at publib.boulder.ibm.com (PDF; 247 kB) – description of basic concepts 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.
Wurzeln im Mainframe-Bereich Die ersten Hypervisoren, die Virtualisierung ermöglichten, waren das von IBM entwickelte Testwerkzeug SIMMON auf Basis der damals neuen System/360-Hardware sowie das Forschungssystem CP-40, das in der ersten Version 1967 fertiggestellt wurde und später zur ersten Version von IBMs 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, dass 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 wurden CP-40 und CP-67 auf ersten Großrechnern eingesetzt. Von 1968 bis 1972 stellte IBM seinen Kunden den Source Code von CP/CMS ohne Support zur Verfügung.
CP/CMS war Teil von IBMs Anstrengungen, ein robustes Time-Sharing-System für seine Großrechner bereitzustellen. Da durch den Hypervisor mehrere Betriebssysteme parallel ausgeführt werden konnten, erhöhte er Zuverlässigkeit und Robustheit: Selbst wenn ein Betriebssystem ausfiel, konnten die anderen Betriebssysteme unbeeinflusst weiterarbeiten. Es erlaubte außerdem den parallelen Betrieb unterschiedlicher (zum Teil experimenteller) Versionen der Betriebssysteme.
IBM kündigte 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ärtskompatibel zu den Serie-S/360 Großrechnern der 1960er Jahre). Die Ankündigung der Unterstützung der Virtualisierung 1972 enthielt auch die Ankündigung 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 lange Zeit immer noch in Form von Sourcecode erfolgte. Das Kürzel „VM“ stand für Virtual Machine – man wollte damit betonen, dass nun alle und nicht nur einige Hardware-Interfaces virtualisiert waren. Sowohl VM als auch CP/CMS erfreuten sich großer Akzeptanz seitens Universitäten, Forschungseinrichtungen, Geschäftskundenanwendern 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-Betriebssystem an Boden – schließlich wurde VM jahrzehntelang als IBMs „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.
Im Jahr 1985 führte IBM den PR/SM Hypervisor und mit ihm das Logical Partitioning genannte Konzept ein, das auch heute noch auf den Plattformen System/390, zSeries, pSeries und iSeries eingesetzt wird.
Ausprägungen Unix- und Linux-Server-Hypervisoren Die großen Unixhersteller, insbesondere Sun Microsystems, HP, IBM and SGI, verkaufen Serverlösungen mit Virtualisierungsunterstützung bereits seit Ende der 1990er 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. IBMs pSeries Server, Sun/Oracles CoolThreads Server und HPs Superdome Server.
Mehrere Einflussfaktoren führten ab 2005 zu einem Wiederaufleben der Bemühungen um die Virtualisierungstechnologien unter den Unix- und Linux-Serverherstellern:
Leistungsfähigere Hardware erlaubt es jeder einzelnen Maschine, mehr Dinge parallel zu bearbeiten Anstrengungen, das Servermanagement und die Konsolidierung vorhandener Server zu vereinfachen Die Notwendigkeit, große Multiprozessor- und 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 Hypervisor-Technologien dargestellt:
Sun/Oracle 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 und Gentoo) und FreeBSD zur Verfügung, die ebenfalls auf dem Sun/Oracles Logical Domains Hypervisor lauffähig sind. Auch Wind River „Carrier Grade Linux“ läuft auf Suns Hypervisor. Volle Virtualisierung auf Basis der SPARC-Prozessoren erwies sich als relativ einfach: Seit seiner Einführung Mitte der 1980er Jahre hatte Sun bewusst darauf geachtet, die Architektur frei von Artefakten zu halten, die der Virtualisierung entgegengestanden hätten.
Sun’s Logical Domains Hypervisor ist ein Typ-1-Hypervisor, da er direkt auf der Hardware ausgeführt wird und die Ausführung der Gastsysteme steuert/überwacht.
HP HP nennt seine Technologie, um mehrere Gastsysteme auf seinen auf dem 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ützung 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.