Nach einem gescheiterten Firmwareupgrade auf den Intel x722 NICs kam der betroffene Host ohne seine 10 Gbit Kerneladapter (vSAN-Network) hoch. Alle Versuche der Wiederherstellung scheiterten und ich musste den Server zu Supermicro einschicken. Klassischer Fall von “bricked device“. Nach Update so funktional wie ein Ziegelstein. Normalerweise wäre das in einem 4-Knoten Cluster keine große Sache. Da aber die Management Adapter funktional waren und die vSAN-Netzwerk Adapter nicht, kam es wohl im Cluster zu Störungen und alle Objekte wurden auf den drei verbleibenden Hosts als “invalid” deklariert.
Ich war zu sehr mit Projektarbeit beschäftigt und hatte ohnehin keine Zeit für Experimente im Lab, also wartete ich bis der 4. Host aus der Reparatur zurück kam. Letzte Woche wurde er endlich geliefert. Sofort baute ich Bootmedium, Cache- und Capacity-Disks wieder ein. Ich prüfte die MAC Adressen und Einstellungen. Alles sah gut aus. Sogar die Firmware war auf neuestem Stand. Nachdem ich den wiedervereinigten Cluster gestartet hatte, blieben die Objekte jedoch weiterhin im Status “invalid”.
Zeit für Troubleshooting
Zuerst startete ich SSH auf allen Hosts. Es gibt zwar einen cleveren powerCLI Befehl der das cluster-weit erledigt, aber ich hatte ja kein vCenter (invalid). Also blieb nur der Hostclient.
Auf der Shell des reparierten Hosts prüfte ich die vSAN-Netzwerk Verbindungen zu allen anderen Hosts im Cluster. Das unten dargestellte Kommando pingt beispielsweise vom Interface vmk1 (vSAN) zur IP 10.0.100.11 (vSAN Kernelport esx01).
vmkping -I vmk1 10.0.100.11
Ich erhielt Antworten aller Kernelports aller Hosts. Ein physische Störung im vSAN Netzwerk konnte also ausgeschlossen werden.
„vSAN Cluster Objekte als invalid deklariert“ weiterlesen