OCe14000-LoM meldet Link Up bei gezogenem Kabel, ESXi-Teaming failovert deshalb nie
Kleiner vSphere-Cluster, zwei 10G-Uplinks pro Host in ein Paar Top-of-Rack-Switches. Nachdem der ToR für ein Firmware-Update neu gestartet wurde, wurden auf einem Host ein Teil der VMs still, und vMotion schlug auf beiden Uplinks fehl - trotzdem hat ESXi nie irgendetwas als down markiert, und die Adapter-LEDs blieben die ganze Zeit an.
- Fujitsu Primergy RX2540 M1
- Emulex OneConnect OCe14000 LAN-on-Motherboard-Adapter (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- SFP+-Optiken in den ToR, einfaches Active/Standby-Teaming auf dem vSwitch
Was mich überzeugt hat, dass es nicht der Switch ist: Ich habe die Faser komplett aus dem Adapter gezogen, und er sieht immer noch lebendig aus.
esxcli network nic get -n vmnic2 (cable physically removed)
Link Status: Up
Firmware Version: 11.2.1194.36
esxcli software vib list | grep elxnet
elxnet 10.2.309.6vSchon versucht:
- die Optik und die Faser neu eingesetzt, das Patchkabel getauscht
- den Uplink auf den anderen ToR-Switch verschoben, dessen Port erwartungsgemäß down geht
- die Management-Agents auf dem Host neu gestartet
Weil der Host glaubt, der Uplink sei live, hat die Teaming-Policy keinen Grund, irgendetwas zu verschieben, und die VMs bleiben an einem toten Port hängen. Ist das ein bekanntes Treiber-gegen-Firmware-Problem bei OneConnect, oder sollte ich mir die LoM-Hardware ansehen?
Comments 6
Diese Kombination ist euer eigenes Verschulden, sie steht bei ESXi 6.0 nicht als unterstützte Paarung. Der Adapter landet halb lebendig: Er bewegt keinen Traffic mehr, meldet den Port aber weiterhin als verbunden, die Teaming-Policy bekommt also nie das Down-Event, das sie zum Handeln braucht. Deshalb kam das bei euch als teilweise Isolation mit totem vMotion auf beiden Uplinks an statt als ehrlicher NIC-Ausfall - eine Karte, die ordentlich stirbt, übersteht man weit leichter als eine, die lügt.
Den Treiber auf 11.2.1149.0 hochziehen. Das ist die elxnet-Stufe, die in der VMware-Kompatibilitätsliste gegen Firmware 11.2.1194.36 qualifiziert ist, ihr bewegt den Treiber also zur Firmware hin, statt die Karte zurückzurollen. Danach mit den zwei Befehlen prüfen, die ihr schon habt:
Die vib-Zeile sollte die neue Version zeigen, und Link Status sollte wieder dem Kabel folgen, sobald der Host zurück ist. Testen, indem ihr bei laufender VM auf diesem Uplink die Faser zieht, bevor ihr dem Cluster damit vertraut.
Die Gewohnheit, die man mitnehmen sollte: Bei OneConnect bewegen sich Treiber und Firmware als Paar, also die beiden gemeinsam einplanen, statt ein Wartungsbundle eines der beiden allein vorziehen zu lassen. Die zwei Zeilen zu vergleichen kostet einen Befehl, und das gehört lange bevor man anfängt, Optiken zu ziehen oder dem Switch die Schuld zu geben.
Die zwei Zeilen, die ihr gepostet habt, sind der interessante Teil: Firmware 11.2.1194.36 läuft unter elxnet 10.2.309.6v. Kam diese Firmware irgendwann getrennt vom Treiber mit einem Server-Wartungsbundle rein?
Diese Paarung gegen die Kompatibilitätsliste für ESXi 6.0 prüfen, nicht gegen "neuestes muss passen". OneConnect ist eine der Familien, bei denen Treiber und Firmware als Paar qualifiziert werden, und ein nicht passendes Paar scheitert nicht zwangsläufig laut - es funktioniert halb, was viel schlimmer ist.
Auch interessant: Verhält sich der zweite Port des Adapters bei gezogenem Kabel genauso?
Ja, die Firmware kam mit einem Server-Wartungsbundle rein; der Treiber wurde seit dem Aufbau des Hosts nicht angefasst.
Beide LoM-Ports verhalten sich identisch: Kabel raus, esxcli network nic get meldet weiterhin Link Status: Up, die LEDs bleiben an, und der vSwitch behält den Uplink in der aktiven Liste. Die Switch-Seite ist sauber, ihr Port geht in dem Moment down, in dem ich abziehe.
Das Einzige, was auf diesem Host also nicht zusammenpasst, ist die elxnet-Version gegen Firmware 11.2.1194.36.
Andere Familie, gleiche Lektion. Ein Paar Emulex-LPe31000/LPe32000-FC-Ports, die ewig unangetastet gelaufen waren, sahen keine LUNs mehr, nachdem ein Proxmox-Kernel auf 5.15.64 und später 5.15.74 gezogen wurde. Verkabelung und Optiken nie angefasst, und das Log sagte:
Das ist eine lpfc-Regression auf der Host-Seite, kein optischer Fehler; sie tauchte in Kerneln nach 5.15.60 auf. Den Boot-Kernel zurückzupinnen war der Workaround, der in Produktion gehalten hat:
Der Opt-in-5.19-Kernel funktionierte auch für Leute, die nichts dagegen hatten, den 5.15-Zweig zu verlassen. Die Reparatur sollte eigentlich in 5.15.77 landen, aber ich bin nie dazu gekommen, diesen Build selbst zu fahren, also als Hörensagen nehmen. Der Punkt bleibt: Wenn ein Link, der früher funktionierte, genau nachdem sich etwas am Host geändert hat, stirbt, erst das Host-Change-Log lesen, bevor man in die Nähe der Transceiver geht.
Ergänze das Spiegelbild davon, weil es denselben Reflex trainiert. Anzeigen sind Software, und Software liegt in beide Richtungen falsch.
Bei EX3400 und EX2300 gibt es einen Junos-Defekt, PR1428703, bei dem die SFP+- und SFP-Port-LEDs dunkel bleiben, während der Link tatsächlich oben ist und Traffic durchlässt. Leute stoßen darauf beim Umzug von 15.1X53 auf die 18.1- und 19.x-Zweige, meist mit DAC. Die CLI widerspricht dem Panel:
meldet die LED als Green, während die physische aus ist. Manche Builds wurden als repariert gemeldet, bei anderen wurden weiter dunkle LEDs berichtet, ich würde das also nicht als sauber abgeschlossen bezeichnen.
Eure ist an bei fehlendem Link, jene ist dunkel bei bestehendem Link. So oder so: dem fernen Ende und den Zählern trauen, nie der Anzeige.
Der Treiber steht jetzt auf beiden Hosts bei 11.2.1149.0. Bei gezogenem Kabel gehen die LEDs aus, esxcli meldet den Link als down, und der Standby-Uplink übernimmt so, wie es immer hätte sein sollen - vMotion lief testweise über jeden Uplink einzeln sauber durch.
Das Treiber-und-Firmware-Paar kommt in unsere Server-Wartungscheckliste, damit das nächste Bundle sie nicht wieder still auseinanderreißt.