Jailhouse: Ein Hypervisor für Multi-Core, Embedded und Echtzeit

Hypervisor Jailhouse: Ein Hypervisor für Multi-Core, Embedded und Echtzeit

16.02.2017Autor / Redakteur: Heinz Egger * / Franz Graser

Auch im Embedded-Umfeld lassen sich viele Vorteile der Hypervisor-Technik anwenden. Die Open-Source-Lösung Jailhouse hat hierfür zahlreiche Trümpfe im Ärmel.

Anbieter zum Thema

Linutronix GmbH

Parasoft® Deutschland GmbH

Bild 1: Systemkonsolidierung mit dem Jailhouse-Hypervisor. Für jede „Cell“, in der ein Gastsystem residiert, ist mindestens ein Prozessorkern erforderlich.
(Bild: Linutronix)

In den letzten Jahren sind IT-Technologien immer schneller in der Industrie akzeptiert worden. Bei dem Thema Hypervisor (oft auch Virtual Machine Manager, kurz VMM, genannt) hat es dennoch etwas gedauert. Hypervisor Lösungen werden seit ihrem ersten Auftreten in den 70er Jahren des letzten Jahrhunderts in Type I (bare–metal) und Type II (host based hypervisor) Lösungen unterschieden. Beiden Ansätzen gemein ist, dass sie virtuelle Maschinen für die einzelnen Gastsysteme vorhalten. Dazu benötigen sie Emulationen der Hardware, um jedem Gastsystem ein vollständiges Hardware-System zur Verfügung stellen zu können.

Hypervisor-Lösungen in der IT erlauben es, Systeme einfach zu skalieren, zu migrieren und zu portieren. Damit können die IT-Systeme dynamisch an die aktuelle Lastsituation angepasst werden und bei Problemen an der HW oder dem Einsatz neuerer Hardware einfach „umziehen“, also auf die neue Hardware übertragen werden. Nebenbei wird die Sicherheit verbessert, da alle virtuellen Systeme untereinander abgeschottet sind. Alte Software kann länger genützt werden, da sie nun in einer eigenen virtuellen Maschine weiterhin auf der neuen Hardware zum Einsatz kommen kann.

Bildergalerie

Bild 2: Hardware-Initialisierung mit Linux.

Bild 4. Latenzen in der "root cell" (rot) und der virtuellen Maschine (blau).

Warum Virtual Machine Manager einsetzen?

Im Embedded-Bereich können viele dieser Vorteile ebenfalls genutzt werden. Bisher auf unterschiedliche Hardware verteilte Lösungen können auf eine Maschine konsolidiert werden. Alte Systeme (bare metal oder alte Betriebssysteme) können weiterhin genutzt werden, HMI (GUI), Echtzeit und SPS oder zertifizierte Programme können nebeneinander auf einer Hardware zum Einsatz kommen. Der Einsatz von dynamischer Lastverteilung ist bei Echtzeitanforderungen allerdings kontraproduktiv.

Die vornehmlich das Thema Security betreffenden Anforderungen aus dem IoT-Umfeld an Embedded-Systeme können mit dem Virtualisierungsansatz gelöst werden, ohne dass die zugrundeliegende Embedded-Applikation neu erstellt werden müsste. Und durch die Aufteilung in mehrere virtuelle Maschinen hat man auch die Probleme, die bei einer Anwendung mit zertifizierter und daher nicht einfach änderbarer Software auf der einen Seite und den ständigen Update-Anforderungen auf der IoT-Seite aufkommen, elegant gelöst.

Welche Hypervisor-Typen gibt es?

Seit den ersten Hypervisor-Lösungen werden diese prinzipiell in zwei große Kategorien, Type I und II, unterteilt. Hier eine kurze Beschreibung der beiden Typen:

Ergänzendes zum Thema

Eine Übersicht über Hypervisor-Typen

Begonnen hat es in den sechziger Jahren des letzten Jahrhunderts, als IBM mit den ersten Forschungsarbeiten über virtuelle Maschinen auf dem Mainframe-Rechner IBM 360 begann. Um die virtuellen Maschinen verwalten zu können, wurde der Virtual Machine Manager (VMM), auch Hypervisor genannt, eingeführt.

1974 veröffentlichten Popek und Goldberg eine Arbeit [1], die wesentliche Eigenschaften eines Hypervisors definiert und seitdem Gültigkeit besitzt. Danach muss ein Hypervisor in der Lage sein, eine virtuelle Umgebung mit folgenden Eigenschaften zur Verfügung zu stellen:

Wiedergabegenauigkeit: eine Software, die in einer virtuellen Maschine (VM) ausgeführt wird, muss sich genauso verhalten, als wenn sie auf der physikalischen Hardware ausgeführt werden würde

Das Ergebnis der Ausführung einer Software in einer virtuellen Maschine darf sich nicht von dem Ergebnis bei einer Ausführung auf der physikalischen Hardware unterscheiden

Leistungsfähigkeit: die Mehrheit der Instruktionen des Gastsystems werden ohne Eingriff des Hypervisors von der Hardware ausgeführt

Sicherheit: Der Hypervisor managt alle verfügbaren Hardware-Ressourcen.

Goldberg hat in seiner Doktorarbeit von 1972 (Principles for Virtual Computer Systems) die noch heute gültige Unterscheidung von Hypervisoren nach der Art und Weise, wie sie auf einer Hardware installiert werden, in Type I und Type II eingeführt.

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

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

Typ-1- und Typ-2-Hypervisoren können noch weiter unterteilt werden in Voll-Virtualisierung, Para-Virtualisierung und Dynamic-Binary-Translation- (DBT) Techniken. Bei einer vollständigen Virtualisierung präsentiert der Hypervisor jedem Gastsystem, unabhängig von der realen Hardware des Host-Systems, eine emulierte Hardware. Bei einer Para-Virtualisierung wird das Gastsystem so geändert, dass es nunmehr nicht mehr mit der realen Hardware, sondern nur noch mit dem Hypervisor kommuniziert.

Das hat den Vorteil, dass nicht für jede VM eine HW emuliert werden muss, das System wird dadurch deutlich performanter. Ein idealer Ansatz für Serversysteme, bei denen mehrere VMs gleichzeitig laufen sollen.

Daneben gibt es noch Betriebssystem-Virtualisierungen, bei dem das Betriebssystem die Hardware in virtuelle Maschinen aufteilt, in denen diese nur ihre eigenen Daten mitzubringen haben, also ähnlich wie bei einer Container Lösung.

Quellen:

[1] G. J. Popek and R. P. Goldberd, “Formal requirements for Virtualizable Third-Generation Architectures,” Communications of the ACM, 1974.

[2] Quelle: https://de.wikipedia.org/wiki/Hypervisor

Type-I-Hypervisoren (bare-metal) laufen direkt auf der Hardware und benötigen daher eine komplette Unterstützung sämtlicher vorhandener physikalischer Schnittstellen auf dem SoC. Denn hier ist es der Hypervisor, der die Hardware initialisieren muss und in Betrieb nimmt. Es wundert daher nicht, dass hier oft Mikrokernel-Lösungen wie beispielsweise L4 zum Einsatz kommen. Nur so lässt sich die komplexe Aufgabenstellung einigermaßen sinnvoll lösen. Type-I-Hypervisoren können zwar die Hardware-basierten Unterstützungen nutzen, die Intel-VT oder AMD-V bieten, aber spätestens bei der Nutzung von virtuellen CPUs oder anderen virtuellen Geräten muss der Hypervisor aktiv werden und die Ressourcen verwalten und zuteilen.

Und das verursacht eine zusätzliche, durch die Software bedingte Latenz im System. Bei Industriesystemen, die auf Echtzeitverhalten (sprich: eine verlässliche, deterministische Reaktion) angewiesen sind, ist das kontraproduktiv. Auch ist die Skalierbarkeit beziehungsweise Portierbarkeit bei derartigen Type-I-Hypervisoren aufgrund Ihrer Komplexität eingeschränkt oder mit hohem Aufwand verbunden.

Type-II-Hypervisoren setzen im Gegensatz dazu auf einem Host-Betriebssystem (BS) auf. Das vereinfacht den Hypervisor und verleiht ihm eine einfachere Portierbarkeit, sofern das Host-OS einfach zu portieren ist oder bereits auf vielen Systemen unterstützt wird. Allerdings müssen hier Zugriffe auf die Hardware, sofern nicht durch die Hardware direkt auf das Gast-OS routbar, durch das Host-OS behandelt werden. Virtuelle CPUs und I/O-Devices benötigen auch hier ein Scheduling, um den Zugriff durch die diversen Gast-Betriebssysteme zu regeln. Auch hier gilt, was schon bei den Type-I-Hypervisor-Lösungen in Bezug auf die Echtzeit gesagt wurde: dieses Verhalten ist kontraproduktiv, da es zusätzliche Verzögerungen (Latenzen) einführt und so den Jitter des Systems vergrößert.