Virtuelle Maschinen auf Red Hat OpenShift mit Service Mesh verwalten

Die Verwaltung virtualisierter Workloads neben containerisierten Anwendungen bleibt eine ständige Herausforderung für IT-Abläufe und führt häufig zu isolierten Verwaltungsumgebungen. Auf dem Red Hat Summit 2026 hatte ich die Gelegenheit, während der OpenShift Spotlight-Session die Bühne zu betreten und zu demonstrieren, wie Red Hat OpenShift diese Kluft überbrückt: Organisationen können eine virtuelle Maschine (VM) und einen Container auf einer einzigen Plattform als gleichwertige Komponenten behandeln.

Alan Cowles präsentiert im Rahmen der OpenShift Spotlight-Session auf dem Red Hat Summit 2026.

Die Lücke zwischen virtuellen Maschinen und Containern schließen

Meine Demonstration konzentrierte sich auf eine fiktive Reiseagenturanwendung, die auf 7 virtuellen Maschinen ausgeführt wurde. Diese Legacy-Anwendung unterstützte die Buchungs- und Abrechnungsfunktionen und verfügte über dedizierte VMs für die verschiedenen Teilfunktionen, die für die Ausführung der Anwendung erforderlich waren. Beispielsweise war eine VM für die Anwendung zur Mietwagenbuchung reserviert, während eine andere ausschließlich Flugreservierungen bearbeitete und eine weitere Hotelunterkünfte arrangierte.

Es zeigt sich, dass Unternehmen in den meisten Fällen getrennte Verwaltungskonsolen für VMs und Container betreiben müssen. Grund dafür ist, dass sie ihre Containerplattformen entweder innerhalb ihrer Virtualisierungslösung hosten oder beide nebeneinander auf einer Bare Metal-Infrastruktur betreiben, verwaltet von separaten Teams. Durch das Hin- und Herwechseln entsteht ein Mehraufwand („Toggle Tax“), der die operative Effizienz beeinträchtigt. In der Demonstration habe ich gezeigt, wie Red Hat OpenShift dies abmildert, indem es virtuelle Maschinen direkt in die nativen Funktionen der Plattform wie Service Mesh integriert.

Da die virtuellen Maschinen in OpenShift selbst in Containern ausgeführt werden, können die von OpenShift bereitgestellten erweiterten Tools einfach auf virtualisierte Workloads angewendet werden, genauso wie auf andere containerisierte Workloads. Mit Red Hat OpenShift Service Mesh habe ich Sidecar-Container in die laufenden VMs eingefügt und so zusätzliche Funktionen bereitgestellt, die zuvor nicht verfügbar waren. Zunächst war der Traffic-Graph leer – die Sidecar-Container waren noch nicht eingefügt! Nach einem kurzen Ausflug auf die Befehlszeile meiner imaginären Tastatur konnte ich einen Service Mesh-Sidecar-Container einfügen – und innerhalb weniger Augenblicke verwandelte sich die Umgebung. Die Pod-Ansicht der VM wurde von 2 auf 3 Container erweitert. Dabei wurde ein istio-proxy-Container neben den guest-console- und compute-Containern hinzugefügt, aus denen die VM besteht. Nach dem Einfügen füllte sich das Service Mesh-Diagramm mit neuen Daten und bot eine umfassende Visualisierung des gesamten Anwendungsablaufs, einschließlich Datenbank- und Supportdiensten. 

 Die Traffic-Graph-Funktion von OpenShift Service Mesh bietet einen umfassenden Überblick über den Anwendungs-Workflow der Reiseagentur. 

Nachdem ich die Netzwerkkonnektivität über das Service Mesh analysiert hatte, zeigte ich der Zielgruppe, dass OpenShift Service Mesh nicht nur für die Visualisierung von Netzwerk-Trafficflows geeignet ist, sondern auch für dessen Steuerung. Um dies zu demonstrieren, zeigte ich ein Canary-Deployment einer aktualisierten Version der Reiseagenturanwendung. Ich habe eine neue VM namens „cars v2“ bereitgestellt und unter Nutzung der Traffic Shaping-Funktionen des Service Mesh ein Deployment eingerichtet, das 90 % des Traffics an die virtuelle Maschine mit der Legacy-Version der Mietwagenanwendung leitet und nur 10 % an Version 2 (um das Auto sozusagen „auf Herz und Nieren zu prüfen“). Sobald ich mich mit der neuen Version sicher fühlte, gab ich einen weiteren Befehl ein, um den Traffic auf ein 80/20-Verhältnis zu verschieben und so die neue Version der Anwendung zu priorisieren. Dies bereitete den logischen nächsten Schritt vor: die Stilllegung der VM, die für die Ausführung der Legacy-Version der Anwendung zuständig war.

Zwar zeigte die Demonstration viele komplexe Interaktionen zwischen Container-Services und den virtuellen Maschinen, die wichtigste Erkenntnis ist jedoch: OpenShift führt VMs nicht einfach nur aus, sondern behandelt sie als native Komponente der modernen, programmierbaren Anwendungsarchitektur. Dies ermöglicht anspruchsvolle Deployment-Strategien, ohne dass Anwendungen komplett neu geschrieben werden müssen.

Durch das Ausführen von VMs in OpenShift kann die Reiseagentur neue Funktionen als native Komponenten in OpenShift mit modernen Rollout-Strategien testen, anstatt Anwendungen neu schreiben zu müssen. 

Mit dieser interaktiven Arcade-Demo können Sie diesen Workflow erkunden und die Funktionen der Plattform aus erster Hand erleben.

Perspektiven aus der Praxis: Der Weg von Abacus

Das Beste an dieser Demonstration ist, dass der von mir gezeigte technische Ansatz keineswegs rein theoretisch ist. Er spiegelt den strategischen Wandel eines unserer Kunden wider. CTO Paul Ponzeka von Abacus, einem Managed Service Provider für die Finanz- und Gesundheitsbranche, begleitete mich auf der Bühne der OpenShift Spotlight-Session und unterhielt sich kurz mit Stu Miniman von Red Hat über den Migrationsweg von Abacus zu OpenShift – angetrieben vom Bedarf an Agilität und als Reaktion auf unhaltbare Praktiken von Anbietern.

Paul Ponzeka, CTO bei Abacus, spricht über die Umstellung von Legacy-VM-Anbietern auf Red Hat OpenShift Virtualization. (20:16)

Auf die Frage, warum Abacus eine Veränderung anstrebte, gab Ponzeka eine offene Markteinschätzung ab und scherzte: „VMware und Broadcom kommen in eine Bar …“ Er ging auf die schwierige Situation ein, mit der viele Serviceanbieter konfrontiert waren: „Wir erlebten eine Verdopplung der Preise, wurden aus der Plattform für Serviceanbieter herausgedrängt … wir mussten etwas grundlegend ändern.“

Für Ponzeka ging es bei dem Schritt nicht nur um das Vermeiden von Preiserhöhungen, sondern auch darum, die Kompetenzen seines Teams für eine modernere, effizientere Architektur zu erweitern. Er betonte, dass die Umstellung auch unerwartete Performance-Verbesserungen mit sich brachte. „Wir haben durch den Wechsel zu OpenShift eine deutlich bessere Performance erreicht. Wir konnten einige unserer größeren Ports mit voller Leitungsgeschwindigkeit betreiben“, berichtete er.

Letztendlich stellte Abacus fest, dass sie durch den Wechsel zu OpenShift die containerisierten Workloads der Kunden wieder On-Premise betreiben konnten – direkt auf Bare Metal neben ihren geschäftskritischen VMs. So wurde aus einer reinen Migrationsnotwendigkeit eine neue Produktlinie – ein Beweis dafür, dass die Befreiung von Legacy-Einschränkungen der erste Schritt zu einer echten Infrastrukturmodernisierung ist.

Fazit

Die VM-Integration von OpenShift ist ein strategischer Wegbereiter für Unternehmen, die einen Vendor Lock-in vermeiden und gleichzeitig ihre Infrastruktur modernisieren möchten. Die von mir geleitete Demonstration verdeutlichte, wie Legacy-Anwendungen in einer modernen cloudnativen Umgebung weiterhin erfolgreich betrieben werden können. Weiterhin bewies der Erfahrungsbericht von Ponzeka für Abacus, dass aus einer Migration ein Wettbewerbsvorteil entstehen kann, der Infrastruktureinschränkungen in neue Geschäftschancen verwandelt. Durch die gleichberechtigte Behandlung von VMs und Containern in einer einheitlichen Anwendungsplattform können Unternehmen bestehende Investitionen erhalten und gleichzeitig die Agilität und Kosteneffizienz cloudnativer Abläufe erreichen. 

Mehr über Red Hat OpenShift Virtualization erfahren 

• Zum Produkt
• Sehen Sie sich die gesamte OpenShift Spotlight-Session an
• Weitere Ressourcen finden Sie im Learning Hub