Wer regelmäßig VCF-Umgebungen aufbaut, kennt das Problem: Der Installer setzt EVC (Enhanced vMotion Compatibility) während des Deployments nicht, und über die API lässt sich das auch nicht erzwingen. Broadcom dokumentiert zwar einen Workaround für die Deploy-Phase, doch was tun, wenn die Umgebung bereits produktiv läuft – besonders wenn der Management-Cluster betroffen ist und vCenter selbst noch kein EVC kennt?
Ein Lösungsweg nutzt Per-VM-EVC als Brücken-Technologie, um die erforderlichen CPU-Feature-Masken zu ermitteln und diese dann gezielt in die vmx-Datei des vCenter-Servers einzupflegen. Der Ablauf ist zwar etwas handwerklich, aber reproduzierbar und vermeidet den kompletten Cluster-Shutdown, den ein nachträgliches EVC-Enable auf Clusterebene sonst erfordern würde.
Informationssammlung als Fundament
Bevor irgendetwas geändert wird, gilt es, den kleinsten gemeinsamen Nenner der CPU-Generationen im Cluster zu bestimmen. Bei Intel-CPUs hilft ein Blick auf ark.intel.com, bei AMD verrät die letzte Ziffer der Modellnummer die Zen-Generation (z. B. 7343 = Zen 3, 9015 = Zen 5). Daraus leitet sich das passende EVC-Level ab – im Beispiel „Sapphire Rapids“. Eine gemeinsame Kompatibilitätsübersicht der möglichen EVC Modi findet man dann passend unter https://compatibilityguide.broadcom.com/search?program=cpu&persona=live
Anschließend wird eine Dummy-VM angelegt (Standard-Assistent, alle Defaults) und per Per-VM-EVC auf genau dieses Level gesetzt. Der Clou: Per-VM-EVC schreibt die vollständige Feature-Mask-Liste in die vmx-Datei der VM. Ein SSH-Zugriff auf einen ESXi-Host des Clusters und ein Blick in diese vmx liefert alle featMask.vm.cpuid.*-Einträge, die später für vCenter benötigt werden. Wichtig: Notieren, auf welchem Host die vCenter-VM aktuell läuft, und sicherstellen, dass der Host Client dort erreichbar ist – vCenter muss später darüber wieder eingeschaltet werden.
Der eigentliche Eingriff
Jetzt wird es ernst: Alle VMs im Cluster, inklusive vCenter, werden heruntergefahren. Im Datastore-Ordner der vCenter-VM wird die vmx-Datei gesichert (cp vcenter.vmx vcenter.vmx.bak) und anschließend mit vi bearbeitet. Ans Dateiende werden alle zuvor kopierten Feature-Mask-Zeilen eingefügt. Nach dem Speichern wird vCenter über den Host Client wieder hochgefahren.
Sobald vCenter vollständig gestartet ist, zeigt der EVC-Reiter der VM ein „Custom Level“ an – das ist in diesem Zwischenschritt erwartetes Verhalten. Nun wird im vSphere Client auf Clusterebene unter Configure → EVC das gewünschte Level (hier Sapphire Rapids) gesetzt und gespeichert. Danach: vCenter wieder herunterfahren, die eingefügten Feature-Mask-Zeilen aus der vmx entfernen, Datei speichern, vCenter erneut starten. Jetzt sollte der EVC-Reiter das Cluster-Level ohne „Custom“-Kennzeichnung anzeigen. Der Cluster ist ab sofort EVC-konsistent, und alle VMs können wieder hochgefahren werden.
Fazit
Der Workaround ist kein Einzeiler, aber er schließt eine Lücke, die der VCF-Installer (Stand 9.0/9.1) offen lässt. Besonders wertvoll: Er funktioniert auch auf dem Management-Cluster, ohne dass ein separates vCenter für die Operation nötig wäre. Wer neue VCF-Umgebungen plant, sollte prüfen, ob sich der Broadcom-Workaround während des Deployments anwenden lässt – das spart den nachträglichen Aufwand. Für bestehende Umgebungen ist die beschriebene Methode derzeit der sauberste Weg, EVC nachzurüsten, ohne den gesamten Cluster kalt zu starten.