Ein Angebot von

Hypervisor

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

| Autor / Redakteur: Heinz Egger * / Franz Graser

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

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.

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.

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

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.

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Ausklappen
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Ausklappen
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44453370 / Open Source)