Eine IPMI-Redfish-Migration steht in vielen Rechenzentren inzwischen als Notwendigkeit auf der Agenda. Im Juni 2020 erklärten die IPMI-Promoter, zu denen Dell, HPE, NEC und Intel gehören, dass es keine weiteren Updates am IPMI-Standard mehr geben wird und Redfish dessen Nachfolger ist (DMTF, 2020).
IPMI wird seit 2020 nicht mehr weiterentwickelt, Nachfolger ist Redfish auf Basis von REST und JSON. Die Redfish-Migration läuft in vier Phasen: Inventur der Redfish-Fähigkeit, Parallelbetrieb beider Protokolle, schrittweise Umstellung der Automatisierung, Abschaltung von IPMI nur dort, wo die Umstellung stabil läuft.
Warum Redfish als Nachfolger von IPMI gilt
IPMI, seit den späten 1990er-Jahren im Einsatz, war für seine Zeit ein Fortschritt. Es lieferte einen Standard für den Fernzugriff auf Serverhardware, der über Herstellergrenzen hinweg funktionierte. Der DMTF, das Standardisierungsgremium hinter beiden Protokollen, beschreibt die zentrale Schwäche von IPMI so: Es ist auf den kleinsten gemeinsamen Nenner ausgelegt (DMTF, 2018). Funktionen, die nicht von jedem Hersteller gleich unterstützt wurden, blieben außen vor oder wurden proprietär nachgerüstet.
| Merkmal | IPMI | Redfish |
|---|---|---|
| Weiterentwicklung | seit 2020 eingestellt | laufend, zuletzt Version 2025.2 |
| Technische Basis | binäres Protokoll | REST und JSON |
| Werkzeuge | eigenes IPMI-Toolset nötig | Standardwerkzeuge, etwa curl |
| Funktionsumfang | kleinster gemeinsamer Nenner | standardisierte Schemas für alle Hersteller |
| Firmware-Update-Service | proprietär je Hersteller | standardisiert seit Version 2016.2 |
Redfish setzt seit der Version 1.0 im August 2015 auf REST und JSON statt auf ein binäres Protokoll (DMTF, 2017). Das klingt zunächst nach einem technischen Detail, hat aber praktische Folgen. Ein curl-Aufruf gegen eine Redfish-Schnittstelle liefert eine lesbare JSON-Antwort, die sich direkt weiterverarbeiten lässt. Die gleiche Abfrage über IPMI verlangt oft ein spezielles Kommandozeilenwerkzeug und die Kenntnis binärer Rückgabecodes, die je nach Hersteller leicht unterschiedlich ausfallen können.
Was Redfish seit der ersten Version dazugewonnen hat
Der Standard wurde seit 2015 kontinuierlich erweitert. Mit Version 2016.2 wurden Firmware-Update-Services erstmals standardisiert und damit bei allen unterstützenden Herstellern über dieselbe Schnittstelle abrufbar (DMTF). Version 2020.4 ergänzte unter anderem Power- und Thermal-Management sowie eigene AccountTypes für KVMIP und Virtual Media, also für genau die Funktionen, die beim Fernzugriff auf Serverkonsolen gebraucht werden (DMTF, 2020).
Die Entwicklung ist damit nicht abgeschlossen. Laut dem DMTF-Newsletter vom August 2025 brachte allein die Version 2025.2 acht neue Schemas und 36 Aktualisierungen bestehender Schemas mit sich. Wer migriert, wechselt also zu einem Standard, der sich weiter verändert.
Die Redfish-Migration in vier Phasen
- Inventur. Welche Server im Bestand unterstützen Redfish bereits nativ, welche nur über ein optionales Firmware-Update und welche gar nicht? Diese Bestandsaufnahme entscheidet über den gesamten weiteren Zeitplan und sollte nicht übersprungen werden, so unspektakulär sie klingt.
- Parallelbetrieb. Neue Automatisierungsskripte werden gegen Redfish geschrieben und getestet, während der produktive Betrieb weiterhin über IPMI abgesichert bleibt. Dieser Parallelbetrieb ist der Kern jeder risikoarmen Redfish-Migration.
- Schrittweise Umstellung. Monitoring, Firmware-Rollouts und Provisioning-Skripte wandern nach und nach von IPMI-Aufrufen zu Redfish-Endpunkten, Server-Gruppe für Server-Gruppe statt auf einen Schlag.
- Abschaltung. IPMI wird nur für die Server abgeschaltet, bei denen die Umstellung vollständig abgeschlossen und über einen längeren Zeitraum stabil gelaufen ist.
Inventur der Redfish-Fähigkeit Ihrer FlotteWir lesen aus, welche Ihrer Server Redfish nativ sprechen, welche ein Firmware-Update brauchen und welche auf IPMI bleiben.
Werkzeuge für die Umstellung
Für die praktische Umsetzung zählt, welche Werkzeuge im eigenen Betrieb bereits vorhanden sind und Redfish sprechen. Viele Automatisierungs- und Verwaltungswerkzeuge unterstützen den Standard inzwischen direkt, oft parallel zur bestehenden IPMI-Anbindung. Auch KVM Fleet setzt bei neueren Servern auf Redfish, um Firmware-Stände und Systeminformationen konsistent über die gesamte Flotte hinweg abzufragen, ohne für jeden Hersteller eine eigene Sonderlösung zu brauchen. Wie sich Firmware-Updates darüber hinaus organisieren lassen, beschreibt der Beitrag zu Firmware-Updates über hunderte Server. Die Architekturfrage dahinter behandelt der Beitrag zu KVM-over-IP im Flottenmaßstab.
Häufige Fragen
Können IPMI und Redfish parallel im selben Betrieb laufen?
Ja, das ist sogar der übliche Weg. Die meisten modernen BMCs unterstützen beide Protokolle gleichzeitig, sodass bestehende IPMI-Skripte weiterlaufen, während neue Automatisierung schrittweise auf Redfish umgestellt wird. Ein harter Umstieg an einem einzigen Stichtag ist selten nötig und in der Praxis auch nicht empfehlenswert.
Was passiert mit alten Servern ohne Redfish-Unterstützung?
Server ohne Redfish-fähigen BMC bleiben auf IPMI angewiesen, solange sie im Einsatz sind. Ein Ersatz allein wegen des Protokolls lohnt sich betriebswirtschaftlich selten, den Ausschlag gibt meist das reguläre Ende der Nutzungsdauer der Hardware.
Welche Verwaltungswerkzeuge sprechen bereits Redfish?
Die großen Serverhersteller bieten eigene Redfish-fähige Werkzeuge für ihre Plattformen an, ergänzt durch Verwaltungslösungen, die den Standard über mehrere Hersteller hinweg unterstützen. Vor der Redfish-Migration lohnt ein Blick in die eigene Werkzeugkette, um zu prüfen, welche Bestandteile bereits Redfish sprechen und wo noch eine Aktualisierung nötig ist.
Der nächste Schritt
KVM Fleet stammt aus der eigenen Entwicklung bei torck und spricht bei neueren Servern bereits Redfish, weil das Team den Umstieg im eigenen Betrieb selbst durchlaufen hat. Einzelne Funktionen der Software sind direkt aus dieser Redfish-Migration entstanden. Mehr dazu auf der Produktseite von KVM Fleet.