NSX reparieren, um ESX erneut in VCF zu importieren
Wenn du hier landest, arbeitest du vermutlich an VMware Cloud Foundation 9.x. Beim Brownfield Import scheitern die ESX Hosts am NSX-Teil. So bringst du sie wieder ans NSX.
Wenn du hier landest, arbeitest du vermutlich an VMware Cloud Foundation 9.x. Die neue Standardplattform für Virtualisierung im Unternehmen bringt einiges an Änderungen mit, wenn du von einfachem vSphere kommst. Wir haben eine Weile mit dem Brownfield Import gespielt und sind über ein paar Stolpersteine gefallen.
Das Problem: NSX scheitert beim Brownfield Import
Wir wollen einen bestehenden vCenter Server in VCF 9.0.x importieren. Das scheitert am NSX-Teil. In unserem Fall haben wir angegeben, dass keine bestehende NSX Installation vorhanden ist. Der Brownfield Import baut also eine neue NSX Instanz für uns auf.
Wenn du vSphere 8.x importierst, musst du drei NSX Manager samt VIP ausrollen. Bei vSphere 9.x kannst du auch ein einfaches Deployment mit einem NSX Manager samt VIP wählen.
In unserem Fall hatten wir vCenter und ESX Hosts vorher schon einmal importiert. Wir haben einiges geändert und wollten es noch einmal machen, um zu sehen, ob es weiterhin funktioniert. Tat es nicht.
Die ESX Hosts konnten sich nicht mit den neuen NSX Managern verbinden.
Lösung A: Hosts mit vSphere 8.x
Auf vSphere 8.x ist es einfach. Wir «löschen» NSX von den ESX Hosts. Dazu verbinden wir uns per SSH mit dem Host.
Auf dem ESX Host gehst du mit «nsxcli» in die nsxcli. Dort tippst du den Befehl «del nsx» und drückst Enter. Bestätige ein paar Mal mit yes und warte dann einige Minuten, während die NSX VIBs entfernt werden. Danach startest du den Host neu.

Lösung B: Hosts mit vSphere 9.x
Nach etwas mehr Spielerei wollten wir den Brownfield Import auch mit einer 9.x-Version von vSphere vollständig durchtesten.
Obwohl wir vorher Lösung A angewendet hatten, scheiterte der Import wieder am NSX-Teil. Bei vSphere 9.x sind die NSX VIBs auf den Hosts vorinstalliert. Der Befehl «del nsx» hat diese VIBs also gar nicht entfernt. Wir mussten also weitergraben.
Diesmal braucht es auf dem ESX Host mehrere Schritte, damit er den NSX Manager wieder erkennt.
Per SSH auf den Host. Verschieb diese XML als Backup: «mv /etc/vmware/nsx/appliance-info.xml /tmp/old_info.xml». Danach leeren wir zwei Zertifikatsdateien, zuerst mit «cat /dev/null > /etc/vmware/nsx/host-cert.pem» und dann mit «cat /dev/null > /etc/vmware/nsx/host-privkey.pem». Anschliessend starten wir ein paar Dienste neu: «/etc/init.d/nsx-proxy restart», «/etc/init.d/nsx-opsagent restart», «/etc/init.d/nsx_cfgagent restart» und «/etc/init.d/nsx-nestdb restart».

Letzter Schritt für beide Lösungen: NSX richten
Falls du denkst, der «Restart Task» in VCF würde danach den NSX Manager automatisch dazu bringen, die Nodes neu auszurollen, dann irrst du dich. Du musst dich am NSX Manager anmelden, auf System – Fabric – Nodes gehen und die Neuinstallation auf den Hosts von Hand anstossen. Erst wenn alle deine ESX Hosts grüne Haken haben, startest du in VCF den «Restart Task».
Beim Brownfielding einer WLD werden in VCF eigentlich zwei Tasks ausgelöst. Damit der Brownfield Import durchläuft, musst du aber nur den mit den mehreren Subtasks neu starten.
Damit sollte dein NSX Brownfield Import laufen. Zumindest dieses eine Problem.
Wie weiter
Wenn du bis hierher gelesen hast, läuft es bei dir vermutlich immer noch nicht. Melde dich bei uns, wir helfen gerne.