L'OCe14000 LoM segnala link up anche a cavo staccato, così il teaming ESXi non fa mai failover
Piccolo cluster vSphere, due uplink 10G per host verso una coppia di switch top-of-rack. Dopo che il ToR è stato riavviato per un aggiornamento firmware, parte delle VM su un host è rimasta muta e la vMotion è fallita su entrambi gli uplink, eppure ESXi non ha mai segnato niente come down e i LED dell'adapter sono rimasti accesi tutto il tempo.
- Fujitsu Primergy RX2540 M1
- adapter LAN-on-motherboard Emulex OneConnect OCe14000 (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- ottiche SFP+ verso il ToR, teaming active/standby semplice sul vSwitch
Cosa mi ha convinto che non è lo switch: ho staccato la fibra dall'adapter completamente e sembra ancora vivo.
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.6vGià provato:
- reinseriti l'ottica e la fibra, cambiato il patch lead
- spostato l'uplink sull'altro switch ToR, la cui porta va down come previsto
- riavviati gli agent di gestione sull'host
Siccome l'host crede che l'uplink sia vivo, la policy di teaming non ha motivo di spostare niente e le VM restano inchiodate su una porta morta. È un problema noto driver-contro-firmware su OneConnect, o dovrei guardare l'hardware del LoM?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
Quella combinazione è colpa tua, e non è elencata come abbinamento supportato per ESXi 6.0. L'adapter finisce mezzo vivo: smette di far passare traffico ma continua a dichiarare la porta come connessa, quindi la policy di teaming non riceve mai l'evento down di cui ha bisogno per agire. Ecco perché ti è arrivata come un isolamento parziale con vMotion morta su entrambi gli uplink invece che come un guasto NIC onesto: una scheda che muore in modo pulito è molto più facile da sopravvivere di una che mente.
Porta il driver alla 11.2.1149.0. Quello è il livello elxnet qualificato contro il firmware 11.2.1194.36 nella lista di compatibilità VMware, quindi stai spostando il driver per raggiungere il firmware invece di far tornare indietro la scheda. Verifica dopo con i due comandi che hai già:
La riga vib dovrebbe mostrare la versione nuova, e Link Status dovrebbe di nuovo seguire il cavo una volta che l'host è tornato su. Testalo staccando la fibra con una VM in esecuzione su quell'uplink prima di fidarti del cluster con esso.
L'abitudine da portarsi a casa: su OneConnect il driver e il firmware si muovono in coppia, quindi pianifica i due insieme invece di lasciare che un bundle di manutenzione ne trascini avanti uno da solo. Confrontare quelle due righe richiede un comando, e va fatto molto prima di iniziare a staccare ottiche o a dare la colpa allo switch.
Le due righe che hai postato sono la parte interessante: firmware 11.2.1194.36 sotto elxnet 10.2.309.6v. Quel firmware è arrivato con un bundle di manutenzione del server a un certo punto, separatamente dal driver?
Controlla quell'abbinamento contro la lista di compatibilità per ESXi 6.0, non contro "il più recente deve andare bene". OneConnect è una delle famiglie dove driver e firmware sono qualificati come coppia, e una coppia disallineata non fallisce necessariamente in modo rumoroso: funziona a metà, il che è molto peggio.
Vale anche la pena dire se la seconda porta dell'adapter si comporta allo stesso modo col cavo staccato.
Sì, il firmware è arrivato con un bundle di manutenzione del server; il driver non è stato toccato da quando l'host è stato costruito.
Entrambe le porte LoM si comportano in modo identico: cavo fuori, esxcli network nic get continua a riportare Link Status: Up, i LED restano accesi, e il vSwitch tiene l'uplink nella lista attiva. Il lato switch è pulito e la sua porta cade nel momento in cui stacco.
Quindi l'unica cosa fuori sincrono su questo host è la versione elxnet contro il firmware 11.2.1194.36.
Famiglia diversa, stessa lezione. Una coppia di porte FC Emulex LPe31000/LPe32000 che giravano intoccate da secoli hanno smesso di vedere qualsiasi LUN dopo che un kernel Proxmox è passato alla 5.15.64 e poi alla 5.15.74. Cablaggio e ottiche mai toccati, e il log diceva:
Quella è una regressione di lpfc lato host, non un guasto ottico; è comparsa nei kernel dopo la 5.15.60. Fissare il kernel di boot all'indietro è stato il workaround che ha retto in produzione:
Anche il kernel opt-in 5.19 ha funzionato per chi non aveva problemi a lasciare il branch 5.15. La correzione doveva arrivare nella 5.15.77, ma non ho mai avuto modo di far girare io stesso quella build, quindi prendilo come sentito dire. Il punto resta: quando un link che funzionava muore subito dopo che qualcosa è cambiato sull'host, leggi il change log dell'host prima di avvicinarti ai transceiver.
Aggiungo l'immagine speculare di questo, perché allena lo stesso riflesso. Gli indicatori sono software, e il software sbaglia in entrambe le direzioni.
Su EX3400 ed EX2300 c'è un difetto Junos, PR1428703, dove i LED delle porte SFP+ e SFP restano spenti mentre il link è genuinamente su e passa traffico. La gente lo incontra passando dalla 15.1X53 ai train 18.1 e 19.x, per lo più con DAC. La CLI è in disaccordo col pannello:
riporta il LED come Green mentre quello fisico è spento. Alcune build sono state segnalate come corrette e i LED spenti continuavano a essere segnalati su altre, quindi non lo definirei chiuso in modo pulito.
Il tuo è acceso senza link, quello è spento con link. In entrambi i casi, fidati dell'altro capo e dei contatori, mai dell'indicatore.
Il driver ora è alla 11.2.1149.0 su entrambi gli host. Con il cavo staccato, i LED si spengono, esxcli riporta il link down, e l'uplink standby subentra nel modo in cui avrebbe sempre dovuto - la vMotion ha girato pulita su ciascun uplink separatamente come test.
La coppia driver-e-firmware sta entrando nella nostra checklist di manutenzione server così il prossimo bundle non li separa più silenziosamente.