Hypervisor

Hypervisor, auch Virtual-Machine-Monitor (aus englisch 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 Peripherie) zu definieren, die unabhängig von der tatsächlich vorhandenen Hardware als Basis für die Installation von (Gast-)Betriebssystemen dient.

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.^[1]

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.^[2]

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.^[3]

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

In seiner Doktorarbeit „Architectural Principles for Virtual Computer Systems“^[4] 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 1^[5] 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.^[6] 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.^[7]

Wurzeln der Virtualisierung 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:^[8]

• 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.^[9] 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.^[9]

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.

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 Betriebssystems HP-UX 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

IBM bietet Virtualisierungsunterstützung durch eine Logical Partitioning (LPAR) genannte Technologie auf den Plattformen System/390, zSeries, pSeries und 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 (LPARs) gewährleistet. Prozessor-Kapazität wird den LPARs entweder explizit zugeteilt oder auf Basis verfügbarer Kapazität dynamisch dort zugeteilt, wo sie wegen hoher Last gerade am dringendsten benötigt wird. 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 Servern mit dem POWER6-Prozessor zur Verfügung. LPAR und MSPP-Kapazitätszuweisungen können angepasst werden. Speicher wird jedem LPAR entweder beim Start fest zugewiesen oder dynamisch bereitgestellt und bezüglich des Adressraums von der PowerVM kontrolliert (zum Schutz der Adressräume der unterschiedlichen VMs). 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 und hohe Verfügbarkeit.

x86-Hypervisor

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) und 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 zur Virtualisierung ausnutzen, sind z. B. VirtualBox, 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 erstmals 2008 ausgelieferten Typ-1-Hypervisor;^[10] Windows-Versionen ab Windows Vista enthalten Erweiterungen, um die Performance zu optimieren, wenn sie basierend auf Hyper-V betrieben werden.

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

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

Storage-Hypervisoren

Hypervisor für eingebettete Systeme

Da eingebettete Systeme (Embedded-Systeme) häufig nur stark beschränkte Ressourcen zur Verfügung haben (insbesondere batteriegetriebene, mobile oder kartenintegrierte „on-chip“ Systeme), 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 müssen zusätzlich bereits unter Berücksichtigung von strengen Echtzeit-Anforderungen entworfen werden.

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

Da Hersteller von eingebetteten 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^[12] diese häufig zur Technologie der Wahl im Embedded-Bereich. ARM bietet mit dem ARM Cortex A15 aber auch einen Highend-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 bezüglich effizienten Sharings von Ressourcen zwischen virtuellen Maschinen, Inter-VM-Kommunikation mit hoher Bandbreite und geringer Latenz sowie feingranularer Kontrolle des Informationsflusses zwischen VMs.^[13]

Anwendungsmöglichkeiten

Auslastung von Hardware

Vor der Virtualisierung benötigte jedes System eigene Hardware. Die mit Abstand meiste Zeit verbringt moderne Hardware jedoch im Leerlauf. Folglich werden Energie und Platz verschwendet. Durch den Betrieb von mehreren Systemen auf derselben Hardware lassen sich die Ressourcen der Hardware besser auslasten und es wird weniger Hardware benötigt. Dies führt zu direkten Kosteneinsparungen für die Betreiber.

Softwareentwicklung

Virtuelle Maschinen mit unterschiedlichen Gastbetriebssystemen erlauben es dem Entwickler, seine Software mit geringem Aufwand auf den gewünschten Zielplattformen zu testen. Falls die zu testende Software gravierende Fehler enthält, beschädigen diese nur das Gastsystem und haben keine Auswirkungen auf das Hostsystem.

Ausfallsicherheit

Durch den Einsatz virtueller Speicherpools oder Failover-Cluster, deren Knoten auf die VMs mehrerer physischer Servern verteilt wurden, lässt sich kostengünstig Ausfallsicherheit erreichen.

Literatur

• R. Goldberg: Architectural Principles for Virtual Computer Systems. Ph.D. thesis, Harvard University, Cambridge, MA, 1972.

Einzelnachweise