OCe14000 LoM rapporteert een actieve link terwijl de kabel eruit is, waardoor ESXi-teaming nooit failovert
Kleine vSphere-cluster, twee 10G-uplinks per host naar een paar top-of-rack switches. Nadat de ToR herstart was voor een firmware-update, viel een deel van de VM's op één host stil en mislukte vMotion op beide uplinks - toch markeerde ESXi nooit iets als down en de adapter-LED's bleven de hele tijd branden.
- Fujitsu Primergy RX2540 M1
- Emulex OneConnect OCe14000 LAN-on-motherboard-adapter (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- SFP+-optiek naar de ToR, gewone active/standby-teaming op de vSwitch
Wat me overtuigde dat dit niet de switch is: ik trok de vezel volledig uit de adapter en hij lijkt nog steeds springlevend.
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.6vAl geprobeerd:
- de optiek en de vezel opnieuw geplaatst, de patchkabel vervangen
- de uplink verplaatst naar de andere ToR-switch, waarvan de poort zoals verwacht down gaat
- de management agents op de host herstart
Omdat de host gelooft dat de uplink leeft, heeft het teamingbeleid geen reden om iets te verplaatsen en blijven de VM's vastgepind op een dode poort. Is dit een bekend driver-versus-firmwareprobleem op OneConnect, of moet ik naar de LoM-hardware zelf kijken?
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
Die combinatie is jouw eigen schuld, en ze staat niet vermeld als ondersteunde koppeling voor ESXi 6.0. De adapter eindigt halfdood: hij stopt met verkeer verplaatsen, maar blijft de poort als verbonden adverteren, dus krijgt het teamingbeleid nooit de down-event die het nodig heeft om te reageren. Daarom kwam dit bij je binnen als een gedeeltelijke isolatie met vMotion dood op beide uplinks, in plaats van een eerlijke NIC-storing - een kaart die netjes doodgaat is veel makkelijker te overleven dan een die liegt.
Breng de driver naar 11.2.1149.0. Dat is het elxnet-niveau dat in de VMware-compatibiliteitslijst gekwalificeerd is tegen firmware 11.2.1194.36, dus beweeg je de driver naar de firmware toe in plaats van de kaart terug te rollen. Controleer daarna met de twee commando's die je al hebt:
De vib-regel zou de nieuwe versie moeten tonen, en Link Status zou de kabel weer moeten volgen zodra de host weer online is. Test het door de vezel eruit te trekken terwijl er een VM op die uplink draait, voordat je de cluster ermee vertrouwt.
De gewoonte die je hieraan moet overhouden: op OneConnect bewegen driver en firmware als paar, dus plan die twee samen in plaats van een onderhoudsbundel er een van in z'n eentje naar voren te laten trekken. Die twee regels vergelijken kost één commando, en dat hoort lang voordat je aan optiek gaat trekken of de switch de schuld geeft.
De twee regels die je plaatste zijn het interessante deel: firmware 11.2.1194.36 draaiend onder elxnet 10.2.309.6v. Is die firmware ooit binnengekomen met een server-onderhoudsbundel, los van de driver?
Controleer die koppeling tegen de compatibiliteitslijst voor ESXi 6.0, niet tegen "nieuwste is vast wel goed". OneConnect is een van de families waar driver en firmware als paar gekwalificeerd worden, en een niet-passend paar faalt niet per se luidruchtig - het werkt half, wat veel erger is.
Ook de moeite waard om te melden: gedraagt de tweede poort van de adapter zich hetzelfde met de kabel eruit?
Ja, de firmware ging erop met een server-onderhoudsbundel; de driver is niet aangeraakt sinds de host gebouwd is.
Beide LoM-poorten gedragen zich identiek: kabel eruit, esxcli network nic get meldt nog steeds Link Status: Up, de LED's blijven branden, en de vSwitch houdt de uplink in de actieve lijst. De switchkant is schoon en die poort valt weg zodra ik de stekker eruit trek.
Dus het enige wat op deze host uit de pas loopt, is de elxnet-versie tegenover firmware 11.2.1194.36.
Andere familie, zelfde les. Een paar Emulex LPe31000/LPe32000 FC-poorten die eeuwenlang ongemoeid hadden gedraaid, zagen geen LUN's meer nadat een Proxmox-kernel naar 5.15.64 en later 5.15.74 ging. Bekabeling en optiek nooit aangeraakt, en het log zei:
Dat is een lpfc-regressie aan de hostkant, geen optisch defect; het dook op in kernels na 5.15.60. De bootkernel terugpinnen was de workaround die het in productie hield:
De opt-in 5.19-kernel werkte ook voor mensen die het niet erg vonden om de 5.15-tak te verlaten. De fix zou in 5.15.77 terechtkomen, maar ik ben er zelf nooit aan toegekomen die build te draaien, dus neem het als horen zeggen. Het punt blijft staan: als een link die vroeger werkte doodgaat vlak nadat er iets op de host veranderde, lees dan het changelog van de host voordat je ook maar in de buurt van de transceivers komt.
Ik voeg het spiegelbeeld hiervan toe, want het traint dezelfde reflex. Indicatoren zijn software, en software heeft het in beide richtingen mis.
Op EX3400 en EX2300 bestaat een Junos-defect, PR1428703, waarbij de SFP+- en SFP-poort-LED's donker blijven terwijl de link echt up is en verkeer doorlaat. Mensen liepen ertegenaan bij de overstap van 15.1X53 naar de 18.1- en 19.x-trains, meestal met DAC. De CLI is het oneens met het paneel:
meldt de LED als Green terwijl de fysieke LED uit is. Sommige builds werden als gerepareerd gemeld en op andere bleven donkere LED's gemeld worden, dus ik zou het geen brandschoon opgelost geval noemen.
Die van jou brandt zonder link, die andere is donker met link. Hoe dan ook: vertrouw het verre uiteinde en de tellers, nooit de indicator.
De driver staat nu op beide hosts op 11.2.1149.0. Met de kabel eruit gaan de LED's uit, meldt esxcli de link als down, en neemt de standby-uplink het over zoals het altijd had moeten gaan - vMotion draaide schoon over elke uplink apart als test.
Het driver-en-firmwarepaar gaat in onze server-onderhoudschecklist, zodat de volgende bundel ze niet stilletjes weer uit elkaar trekt.