imported>Wurgl: doppelten Parameter entfernt, Commonscat mit Helferlein hinzugefügt

2025-11-24T07:45:10Z

doppelten Parameter entfernt, Commonscat mit Helferlein hinzugefügt

Neue Seite

'''Hypervisor''', auch '''Virtual-Machine-Monitor''' (aus [[englische Sprache|englisch]] ''{{lang|en|virtual machine monitor}}'', kurz '''VMM''') genannt, ist eine Software oder [[Firmware]], die [[virtuelle Maschine]]n erstellt und verwaltet.<ref>{{Internetquelle |url=https://student.cs.uwaterloo.ca/~cs350/W21/notes/wrapup-1up.pdf |titel=Virtual Machines |abruf=2025-11-23}}</ref><ref>{{Internetquelle |url=https://www.shobhituniversity.ac.in/pdf/econtent/Cloud-Computing-Unit-I-Mr-Avinav-Pathak.pdf |titel=Cloud Computing Virtualization Concepts |sprache=en |abruf=2025-11-23}}</ref> Die Funktion in modernen Computern erlaubt es eine virtuelle Umgebung (Hardwareressourcen, insbesondere [[Prozessor|CPU]], [[Datenspeicher|Speicher]], Festplattenspeicherplatz und verfügbare [[Peripheriegerät|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 [[Betriebssystem]]en 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 [[Privilegienstufe|Kernel-Space]]-Funktionalität und VMM auf [[Privilegienstufe|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 [[X86-Virtualisierung|Intel VMX]]. Mikrokerne, die Virtualisierungsmechanismen implementieren, werden auch ''Microhypervisor'' genannt.<ref>{{cite conference | last = Steinberg | first = Udo | last2 = Kauer | first2 = Bernhard | title = NOVA: A Microhypervisor-Based Secure Virtualization Architecture | book-title = Proceedings of the 2010 ACM European Conference on Computer Systems | date = 2010 | location = Paris, France | url = https://hypervisor.org/eurosys2010.pdf | access-date = 2024-09-28 | language=en | conference=EuroSys 2010}}</ref><ref>{{cite web | url = https://github.com/cyberus-technology/hedron | title = Hedron Microkernel | website = GitHub | publisher = Cyberus Technology | access-date = 2024-08-27 | lang=en-US}}</ref> Wenn man diese Terminologie auf [[Linux]] anwendet, dann ist [[Kernel-based Virtual Machine|KVM]] ein ''Hypervisor'' und [[QEMU]] oder auch [[Cloud Hypervisor]] sind VMMs, die KVM als Hypervisor nutzen.<ref>{{cite web | url = https://github.com/cloud-hypervisor/cloud-hypervisor | title = Cloud Hypervisor | website = GitHub | publisher = Cloud Hypervisor Project | access-date = 2024-08-27 | lang=en-US}}</ref>

== 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 (Informatik)|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.<ref>{{cite news|url=https://www.hyper-v-server.de/tag/hyper-v-buch/|title=Microsoft Hyper-V|publisher=Rheinwerk Computing}}</ref>

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 [[Virtualisierungsforderungen von Popek und Goldberg|grundlegenden Anforderungen]] an eine Architektur dar, um Hypervisoren zu unterstützen.<ref>{{cite journal|author=Gerald J. Popek and Robert P. Goldberg | title=Formal Requirements for Virtualizable Third Generation Architectures |language=en | journal=Communications of the ACM | year=1974 | volume=17 | issue=7 | pages=412–421| doi=10.1145/361011.361073}}</ref>

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.<ref>{{Webarchiv|text=''Everything you need to know about the Intel Virtualization Technology'' |url=http://www.hardwaresecrets.com/article/Everything-You-Need-to-Know-About-the-Intel-Virtualization-Technology/263/1 |wayback=20140819090541 }}</ref>

== 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 ==
[[Datei:VMM-Type1.JPG|mini|hochkant=1.3|Typ-1-Hypervisor]]
[[Datei:VMM-Type2.JPG|mini|hochkant=1.3|Typ-2-Hypervisor]]

In seiner Doktorarbeit „Architectural Principles for Virtual Computer Systems“<ref>{{Literatur|Autor=Robert P. Goldberg|Titel=Architectural Principles for Virtual Computer Systems|Datum=1973-02-01|Online=http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=AD0772809|Abruf=2017-01-24}} {{Webarchiv|url=http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=AD0772809 |wayback=20170124133920 |text=Architectural Principles for Virtual Computer Systems }}</ref> 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<ref>[http://www.computerwoche.de/a/alles-ueber-virtualisierung,2350017,4 ''Alles über Virtualisierung''.] In: ''[[Computerwoche]]'', abgerufen am 16. August 2014.</ref> 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.<ref>''IBM Systems Virtualization'', IBM Corporation, Version 2 Release 1 (2005), available on-line at [http://publib.boulder.ibm.com/infocenter/eserver/v1r2/topic/eicay/eicay.pdf publib.boulder.ibm.com] (PDF; 247 kB) – description of basic concepts</ref> 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.<ref>{{Internetquelle |url=https://www.vmware.com/de/products/vsphere-hypervisor.html |titel=Was ist vSphere Hypervisor? |abruf=2022-07-08}}</ref>

== {{Anker|Historie Virtualisierung}} 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/CMS|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 [[Virtueller Speicher|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 [[Compatible Time-Sharing System|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/CMS|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 (Betriebssystem)|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 [[Multiple Virtual Storage|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 [[LPAR|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:<ref>{{Webarchiv |url=http://searchenterpriselinux.techtarget.com/news/1152219/Xen-virtualization-quickly-becoming-open-source-killer-app |wayback=20110417220911 |text=virtualization quickly becoming open source ‘killer app’}}</ref>

* 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 (Betriebssystem)|Solaris]] immer das einzige offiziell durch [[Sun Microsystems|Sun]]/[[Oracle]] unterstützte Gastsystem auf ihrem Logical Domains Hypervisor war, stehen seit Ende 2006 Portierungen von [[Linux]] ([[Ubuntu (Betriebssystem)|Ubuntu]] und [[Gentoo Linux|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.<ref name="windriver">{{Webarchiv |url=http://www.windriver.com/news/press/pr.html?ID=3881 |wayback=20061110175456 |text=Wind River To Support Sun’s Breakthrough UltraSPARC T1 Multithreaded Next-Generation Processor}}</ref> 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.<ref name="windriver" />

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 ====
[[Hewlett-Packard|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-[[Hot Swapping|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 [[LPAR|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 ===
{{Hauptartikel|x86-Virtualisierung}}

2005 haben die [[x86-Prozessor#Hersteller|CPU-Hersteller]] im [[x86-Architektur|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 vSphere|VMware ESX/ESXi]], [[Kernel-based Virtual Machine|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;<ref>{{Internetquelle |url=https://www.eweek.com/news/microsoft-sheds-more-light-on-windows-hypervisor-technology/ |autor=Peter Galli |titel=Microsoft Sheds More Light on Windows Hypervisor Technology |werk=eweek.com |datum=2006-04-05 |sprache=en |abruf=2023-01-31}}</ref> [[Windows]]-Versionen ab [[Windows Vista]] enthalten Erweiterungen, um die Performance zu optimieren, wenn sie basierend auf Hyper-V betrieben werden.

Bei [[VMware vSphere|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 ===
{{Hauptartikel|Storage-Hypervisor}}

=== {{Anker|Embedded}} Hypervisor für eingebettete Systeme ===
Da [[Eingebettetes System|eingebettete Systeme]] (Embedded-Systeme) häufig nur stark beschränkte Ressourcen zur Verfügung haben (insbesondere batteriebetriebene, 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-[[Echtzeitbetriebssystem]]e (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-Architektur]]en 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 [[Ring (CPU)|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-Architektur|MIPS-]], [[ARM-Architektur|ARM-]] und [[PowerPC]]-Architekturen als weitverbreiteten Architekturen im Embedded-Umfeld unterstützt.<ref>{{Literatur |Autor=Marius Strobl |Titel=Virtualization for Reliable Embedded Systems |Online=https://www.grin.com/document/233001 |Datum=2013 |Hrsg=GRIN Publishing GmbH |Ort=Munich |ISBN=978-3-656-49071-5 |Seiten=5–6}}</ref>

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]]<ref>{{Internetquelle |url=https://www.sysgo.com/virtualization |titel=Virtualization {{!}} SYSGO |abruf=2022-07-08}}</ref> diese häufig zur Technologie der Wahl im Embedded-Bereich. [[ARM Limited|ARM]] bietet mit dem [[ARM Cortex-A#ARM Cortex-A15|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.<ref name="Hei08">{{cite conference |conference=Eurosys '08: Eurosys 2008 Conference Glasgow Scotland 1 April 2008 |author=Gernot Heiser |title=The role of virtualization in embedded systems | language=en |book-title=Proc. 1st Workshop on Isolation and Integration in Embedded Systems (IIES'08) |pages=11–16 |date=2008-04 |url=http://ertos.nicta.com.au/publications/papers/Heiser_08.abstract |accessdate=2014-08-16 |archiveurl=https://web.archive.org/web/20120321212358/https://ertos.nicta.com.au/publications/papers/Heiser_08.abstract |archivedate=2012-03-21 |offline=yes}}</ref>

== Anwendungsmöglichkeiten ==
{{Überarbeiten}}

=== 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.

== Weblinks ==
{{Commonscat}}

== Einzelnachweise ==
<references responsive />

[[Kategorie:Virtualisierung]]

Hypervisor - Versionsgeschichte

imported>Wurgl: doppelten Parameter entfernt, Commonscat mit Helferlein hinzugefügt