VMware-Host-Austausch: ESXi-Hosts schrittweise im Cluster oder über einen neuen Cluster ersetzen

So ersetzen Sie ESXi-Hosts in einem VMware-Cluster

Ein VMware-Host-Austausch, also der Hardware-Refresh eines vSphere-Clusters, folgt einem von zwei Mustern. Beim schrittweisen Austausch (Rolling Replacement) treten neue Hosts dem bestehenden Cluster bei und die alten verlassen ihn nacheinander, während Enhanced vMotion Compatibility (EVC) vMotion über CPU-Generationen hinweg funktionsfähig hält und vSAN die Daten jedes alten Hosts verschiebt, bevor er geht. Beim zweiten Muster bauen Sie neben dem alten Cluster einen neuen auf und verschieben die VMs per vMotion hinüber, wobei Compute und Storage in einem Schritt wechseln. Beide Wege halten die VMs in Betrieb, solange alte und neue Hosts CPUs desselben Herstellers verwenden. Ein Wechsel von Intel zu AMD oder zurück erfordert Cold Migration, bei der jede VM ausgeschaltet ist. Broadcom nennt den Hypervisor ab Version 9.0 ESX und bis 8.x ESXi.

Zum ersten Muster hält Broadcoms EVC-FAQ, KB 313545, fest: „Mit EVC lassen sich vollständige Cluster-Upgrades ganz ohne Ausfallzeit virtueller Maschinen erreichen.“ Welches Muster passt, hängt von der vSAN-Architektur ab, vom vLCM-Image, von der ESX-Version, die die neuen Server brauchen, und von der Lizenzkapazität während der Überlappung.

Broadcom KB 313545, KB 432894, KB 444762 und KB 424294; Dokumentation zu vSphere 8.0 über CPU-Kompatibilität, EVC und Migration (16. September 2026); Lizenzmodell von VCF 9.0 (29. September 2026). Die Zeilen zu Rollback und Lizenzen sind unsere Lesart dieser Regeln.

Unsere VMware-Optimierung führt clusterübergreifende Migrationen in vereinbarten Wartungsfenstern durch, Schritt für Schritt, mit einem Rollback-Plan für jede Etappe. Nennen Sie uns, wie viele Hosts und Cluster Sie ersetzen, mit den CPU-Modellen auf beiden Seiten.

Schrittweiser Austausch im bestehenden Cluster

Der schrittweise Austausch passt zu einem Cluster, dessen neue Server CPU-Hersteller, vSAN-Architektur und Serverhersteller der alten beibehalten. KB 444762 hält fest, dass „vSAN architektonische Konsistenz über alle Knoten hinweg erfordert“, und laut KB 424294 werden vLCM-Images für Cluster mit heterogener Hardware „erst ab ESX 9 unterstützt“. Fügen Sie den neuen Host hinzu, bevor Sie einen alten entfernen. Broadcoms Seite zu VCF 9.0 über das Hinzufügen eines Hosts zu einem vSAN-Cluster sagt, dass der Host „in den Wartungsmodus wechselt, bevor der ESX-Host hinzugefügt wird“, bittet Sie zu bestätigen, dass seine Treiber, seine Firmware und seine Storage-I/O-Controller im Broadcom Compatibility Guide (BCG) gelistet sind, und empfiehlt einheitlich konfigurierte Hosts.

Bei drei Hosts ist Ensure accessibility „der einzige verfügbare Evakuierungsmodus“, und Broadcoms Seite zum Wartungsmodus nennt ihn „nicht geeignet, wenn Sie den Host dauerhaft aus dem Cluster entfernen möchten“. Ein vierter Host mit freier Kapazität, der zuerst hinzugefügt wird, macht Full data migration möglich. Vor jeder Evakuierung zeigen der Pre-Check zur Datenmigration und der Dialog Confirm Maintenance Mode, ob die Kapazität ausreicht, wie viele Daten verschoben werden und wie viele Objekte nicht konform oder nicht zugänglich würden.

Broadcom TechDocs, vSAN 8.0 Administration, ein Mitglied eines vSAN-Clusters in den Wartungsmodus versetzen (9. September 2026); KB 326861 und KB 432894, gelesen am 10. Oktober 2026.

Die Grenzwerte von vSphere 8.0 erlauben 8 gleichzeitige vMotion-Migrationen je Host bei 10 GbE und 4 bei 1 GbE, ein Host mit 40 VMs leert sich also in mindestens fünf Durchgängen. KB 326861 für vSAN 7.x und 8.x nennt danach die Schritte zur Außerbetriebnahme: warten, bis die Resynchronisierung abgeschlossen ist, die Datenträgergruppen bei OSA oder die Datenträger bei ESA entfernen, den Host aus dem Cluster verschieben, seine verbliebenen Unicast-Agent-Einträge auf den übrigen Hosts entfernen und ihn herunterfahren.

Neuer Cluster neben dem alten: vMotion zwischen Clustern

Ein neuer Cluster passt, wenn vSAN von OSA zu ESA wechselt, wenn die neuen Server von einem anderen Hersteller kommen und eigene Hersteller- und Firmware-Add-ons brauchen oder wenn der alte Cluster als Weg zurück unverändert bleiben soll. Broadcoms KB 432894 sagt: „Eine direkte Migration von vSAN OSA zu ESA ist nicht möglich“, weil beide „grundlegend unterschiedliche On-Disk-Formate und Datenpfade verwenden“, und der dort beschriebene Weg im Parallelbetrieb baut einen neuen ESA-Cluster auf und verschiebt die VMs per Storage vMotion. Unser Vergleich von vSAN ESA und OSA behandelt die ESA-ReadyNode-Profile für die neuen Hosts.

Innerhalb eines vCenter hält Broadcoms Dokumentation zu vSphere 8.0 fest, dass „vSphere vMotion auf einen anderen Host und Datenspeicher in vSphere-Umgebungen ohne gemeinsam genutzten Speicher möglich ist“, und jeder Host „muss für vSphere vMotion lizenziert sein“. Ein solcher Umzug zählt als vMotion ohne gemeinsam genutzten Speicher, den die Grenzwerte von 8.0 auf 2 gleichzeitige Vorgänge je Host begrenzen, gegenüber 8 für vMotion allein. Die Aufteilung einer neuen Umgebung in Cluster behandelt unser Leitfaden zum Design von vSphere-Clustern.

Wechsel des CPU-Herstellers: Cold Migration zwischen Intel und AMD

Für die Live-Migration verlangt die Dokumentation zu vSphere 8.0, „dass die Prozessoren des Zielhosts der virtuellen Maschine dieselben Befehle bereitstellen“, und die Prozessoren „müssen aus derselben Herstellerklasse (AMD oder Intel) stammen, um vMotion-kompatibel zu sein“. EVC ändert daran nichts, denn laut KB 313545 „lässt ein Cluster mit aktiviertem EVC nur CPUs eines einzigen Herstellers im Cluster zu“.

Cold Migration ist der dokumentierte Weg. Laut Broadcom „gelten CPU-Kompatibilitätsprüfungen nicht, wenn Sie ausgeschaltete virtuelle Maschinen per Cold Migration migrieren“, und eine angehaltene VM muss die CPU-Anforderungen ihres neuen Hosts weiterhin erfüllen, daher braucht ein Umzug zu einem anderen Hersteller eine ausgeschaltete VM. Die Ausfallzeit je VM umfasst das Herunterfahren des Gastsystems, das Kopieren ihrer Dateien, wenn sich der Datenspeicher ändert, und den ersten Start auf dem neuen Host; planen Sie sie daher je Anwendung in Wartungsfenstern.

EVC-Modus für die neuen Hosts: wählen, anheben, absenken

KB 313545 erklärt, wie Sie die EVC-Modi finden, die eine CPU unterstützt: im BCG nach dem Servermodell oder der CPU-Familie suchen, die CPU-Serie auswählen und für 8.0 Update 3 und 9.x „Enhanced vMotion Capability Modes“ öffnen. Die neuesten Modi in seiner Liste, die vCenter 8.0 Update 1 und 2 abdeckt, Stand 10. Oktober 2026, sind Intel „Sapphire Rapids“, das Emerald Rapids einschließt, und AMD „Zen 4“; für spätere Prozessoren ist der BCG-Eintrag des Servers maßgeblich. KB 450883 ergänzt, dass VMs mit RHEL 8 auf einer Granite-Rapids-Baseline auf Ice Lake zurückfallen, prüfen Sie also zuerst die Unterstützung der Gastsysteme.

Setzen Sie EVC, bevor der erste neue Host beitritt. Läuft der Cluster heute ohne EVC, aktivieren Sie es auf der Generation der alten Hosts; die Anweisung, VMs auszuschalten, gilt nur für VMs auf Hosts „mit einem größeren Funktionsumfang als der EVC-Modus“, den Sie aktivieren. Wenn der letzte alte Host gegangen ist, heben Sie den Modus an. Laut der Dokumentation zu 8.0 „können laufende virtuelle Maschinen eingeschaltet bleiben“, doch neue Funktionen erreichen sie erst nach einem vollständigen Aus- und Einschalten, und „ein Neustart des Gastbetriebssystems oder das Anhalten und Fortsetzen der virtuellen Maschine reicht nicht aus“. Wird vmx.reboot.powerCycle auf TRUE gesetzt, wird der nächste Neustart des Gastsystems zu einem Aus- und Einschalten. Ein späteres Absenken des Modus erfordert das Ausschalten der VMs, die darüber laufen; behalten Sie in einem neuen Cluster daher den Modus des alten Clusters bei, bis der alte Cluster abgebaut ist.

ESX-Version, vLCM-Image und vSAN-Listung der neuen Hosts

Ist das neue Servermodell im BCG nur für ESX 9 gelistet, aktualisieren Sie zuerst vCenter. KB 424129 hält fest, dass „vCenter 9.0 Hosts mit ESX 8.0 im selben Cluster wie Hosts mit ESX 9.0 verwalten kann“. Alte Hosts mit Cascade-Lake-Xeons oder Prozessoren der Serie EPYC 7002 sind laut KB 318697 für VCF 9.x veraltet, wobei die KB ergänzt: „Deprecated Mode bedeutet, dass es weiterhin von VMware unterstützt wird“. Welche bestehenden Hosts ESX 9 ausführen, steht in unserem Leitfaden zu den Hardware-Anforderungen für ESX 9.

Tritt ein Host einem Cluster bei, der mit einem Image verwaltet wird, fordert der Assistent zum Hinzufügen von Hosts Sie auf, das vorhandene Cluster-Image auszuwählen oder eines von einem Host zu importieren. Bereiten Sie dieses Image vor, bevor die Server eintreffen, mit dem Basis-Image, dem Hersteller-Add-on des Serverherstellers und, für die Firmware, seinem Hardware Support Manager. Cluster, die noch mit Baselines arbeiten, und Cluster mit Servern verschiedener Hersteller behandelt unser Leitfaden zur Umstellung von vLCM-Baselines auf Images.

Lizenzen während der Überlappung und für ausgemusterte Hosts

Broadcoms Lizenzmodell für VCF 9.0 hält fest: „Die einzigen Assets in Ihrer Umgebung, die die Kapazität Ihrer primären Lizenzen verbrauchen, sind ESX-Hosts“, mit mindestens 16 Kernen je physischer CPU, und Lizenzen werden nur vCenter-Instanzen zugewiesen. Solange alte und neue Hosts dasselbe vCenter teilen, verbrauchen beide Kerne. Ein Host, der ohne freie Kapazität hinzugefügt wird, bleibt bis zu 90 Tage im Evaluierungsmodus, gerechnet ab der Installation von ESX 9.0, und wird danach von vCenter getrennt.

Für VCF 9.1 beschreibt KB 445407, wie Kapazität zurückkommt: Hosts, die nicht mehr verwaltet werden müssen, aus dem vCenter-Inventar entfernen oder sie in SDDC Manager außer Betrieb nehmen, wo dieser sie verwaltet, und VCF Operations 5 bis 10 Minuten Zeit geben, die Kerne zurückzugewinnen. Die Zählregeln stehen in unserem Leitfaden zur VMware-Lizenzierung, Zahl und Kernzahl der neuen Hosts in unserem Leitfaden zur Host-Konsolidierung bei Lizenzierung pro Kern.

Ablauf des Austauschs, Schritt für Schritt

Die Reihenfolge stammt von uns, aufgebaut aus den oben genannten Broadcom-Dokumenten, mit einem Rollback-Punkt nach jedem Schritt.

1. Erfassen Sie je Cluster den Bestand: Host- und CPU-Modelle, EVC-Modus, vSAN-Architektur, vLCM-Image, Versionen von vCenter und ESX oder ESXi.
2. Prüfen Sie das neue Servermodell, die CPU, Adapter, Laufwerke und Controller im BCG für das Ziel-Release von ESX.
3. Wählen Sie je Cluster schrittweisen Austausch oder neuen Cluster und bestätigen Sie die Lizenzkapazität für die Überlappung.
4. Aktivieren oder bestätigen Sie EVC im Modus der alten Hosts und aktualisieren Sie vCenter, wo die neuen Hosts es erfordern.
5. Bereiten Sie das Cluster-Image sowie das vMotion- und vSAN-Netzwerk für die neuen Hosts vor.
6. Fügen Sie den ersten neuen Host hinzu, gleichen Sie ihn per Remediation mit dem Image ab und prüfen Sie den vSAN-Zustand, bevor eine VM umzieht.
7. Evakuieren Sie nach dem Pre-Check einen alten Host mit Full data migration oder verschieben Sie einen Teil der VMs per vMotion in den neuen Cluster.
8. Nehmen Sie den alten Host außer Betrieb: Datenträger oder Datenträgergruppen entfernt, Host aus dem Cluster und aus dem vCenter-Inventar.
9. Heben Sie nach dem letzten alten Host den EVC-Modus an und schalten Sie die VMs in Wartungsfenstern aus und wieder ein.
10. Löschen und dokumentieren Sie die alten Laufwerke, bevor sie Ihre Kontrolle verlassen.

Wir liefern die neuen Server mit Herstellergarantie, das Engineering übernimmt unser Engineering-Partner Vixen.UNO. Schreiben Sie uns Ihre Clusterliste und die Termine für den Austausch, dann gehen wir die Reihenfolge der Schritte mit Ihnen durch.

Alte Hosts ausmustern und ihre Laufwerke sicher löschen

NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization, veröffentlicht im September 2025, ersetzt Rev. 1 aus dem Jahr 2014. Von ihren drei Methoden wendet Clear logische Verfahren auf „alle vom Benutzer adressierbaren Speicherorte“ an, gegen einfache, nicht invasive Wiederherstellung. Purge macht „die Wiederherstellung der Zieldaten undurchführbar“, auch mit Labormethoden, und lässt das Laufwerk potenziell wiederverwendbar; Destroy erreicht dasselbe Niveau und macht das Laufwerk für Daten unbrauchbar. Rev. 2 verweist für medienspezifische Verfahren auf IEEE 2883 und verlangt, dass das Ergebnis verifiziert wird und je Gerät „ein Bereinigungszertifikat“ vorliegt, mit Modell, Seriennummer, Methode, Werkzeug und Verifizierung.

Rev. 2 behandelt Laufwerke, die im Rahmen der Garantie getauscht und nicht zurückgegeben werden, als außerhalb der Kontrolle der Organisation. Für vSAN führten die Release Notes zu vSAN 7.0 Update 1 PowerCLI- und API-Befehle ein, um „Flash-Speichergeräte vor der Außerbetriebnahme aus einem vSAN-Cluster sicher zu löschen“. Bootgeräte und lokale VMFS-Datenträger gehören in dieselbe Dokumentation.

Was wir tun

Eurokommerz hält den Vertrag und liefert die Hardware zur Lösung, mit EU-Rechnungsstellung, Lieferung und Garantie nach europäischem Recht. Im Rahmen der VMware-Optimierung erstellt unser Engineering-Partner Vixen.UNO eine vollständige Inventur Ihrer VMware-Umgebung und Lizenzen und modernisiert vSphere, vSAN, NSX und VCF, clusterübergreifende Migrationen eingeschlossen. Änderungen laufen in vereinbarten Wartungsfenstern mit einem Rollback-Plan für jede Etappe, danach folgt Support unter einem vereinbarten SLA. Das erste Gespräch ist kostenlos, und der Preis der technischen Bewertung wird vor Beginn der Arbeiten festgelegt.

FAQ