OCe14000 LoM zgłasza link up z wyjętym kablem, więc teaming ESXi nigdy nie przełącza się awaryjnie
Mały klaster vSphere, dwa uplinki 10G na hosta do pary switchy top-of-rack. Po restarcie ToR z powodu aktualizacji firmware część maszyn wirtualnych na jednym hoście ucichła, a vMotion padł na obu uplinkach - a mimo to ESXi nigdy nie oznaczył niczego jako down, a diody adaptera cały czas świeciły.
- Fujitsu Primergy RX2540 M1
- adapter LAN-on-motherboard Emulex OneConnect OCe14000 (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- optyka SFP+ do ToR, zwykły teaming active/standby na vSwitchu
Co mnie przekonało, że to nie switch: wyjąłem światłowód z adaptera całkowicie, a on nadal wygląda na żywy.
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.6vJuż próbowałem:
- wyjąłem i osadziłem ponownie optykę i światłowód, podmieniłem patchcord
- przeniosłem uplink na drugi switch ToR, którego port pada tak, jak powinien
- zrestartowałem agentów zarządzania na hoście
Ponieważ host wierzy, że uplink żyje, polityka teamingu nie ma powodu, żeby cokolwiek przełączyć, a maszyny wirtualne zostają przypięte do martwego portu. Czy to znany problem sterownik-kontra-firmware na OneConnect, czy powinienem patrzeć na sprzęt 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
Ta kombinacja to twoja wina, i nie jest wymieniona jako wspierane zestawienie dla ESXi 6.0. Adapter kończy na wpół żywy: przestaje przesyłać ruch, ale dalej zgłasza port jako podłączony, więc polityka teamingu nigdy nie dostaje zdarzenia down, którego potrzebuje, żeby zadziałać. Dlatego dotarło to do ciebie jako częściowa izolacja z martwym vMotion na obu uplinkach, zamiast jako uczciwa awaria karty sieciowej - karta, która umiera porządnie, jest dużo łatwiejsza do przeżycia niż taka, która kłamie.
Podnieś sterownik do 11.2.1149.0. To poziom elxnet zakwalifikowany wobec firmware 11.2.1194.36 na liście kompatybilności VMware, więc przesuwasz sterownik, żeby dogonił firmware, a nie cofasz kartę. Sprawdź potem tymi dwoma poleceniami, które już masz:
Linia vib powinna pokazać nową wersję, a Link Status powinien znowu podążać za kablem, gdy host wróci. Przetestuj to, wyjmując światłowód z działającą maszyną wirtualną na tym uplinku, zanim zaufasz temu klastrowi.
Nawyk wart zapamiętania: w OneConnect sterownik i firmware poruszają się jako para, więc planuj oba naraz, zamiast pozwalać, żeby pakiet serwisowy pociągnął jedno z nich do przodu samodzielnie. Porównanie tych dwóch linii to jedno polecenie i należy do tego, co robi się długo przed wyjmowaniem optyki albo obwinianiem switcha.
Te dwie linie, które wkleiłeś, to ciekawa część: firmware 11.2.1194.36 działający pod elxnet 10.2.309.6v. Czy ten firmware przyszedł w jakimś momencie z pakietem serwisowym serwera, osobno od sterownika?
Sprawdź to zestawienie na liście kompatybilności dla ESXi 6.0, a nie według zasady "najnowsze musi być dobre". OneConnect to jedna z rodzin, gdzie sterownik i firmware są kwalifikowane jako para, a niedopasowana para niekoniecznie zawodzi głośno - działa na wpół, co jest dużo gorsze.
Warto też powiedzieć, czy drugi port adaptera zachowuje się tak samo z wyjętym kablem.
Tak, firmware poszedł z pakietem serwisowym serwera; sterownika nikt nie ruszał, odkąd host powstał.
Oba porty LoM zachowują się identycznie: kabel wyjęty, esxcli network nic get nadal zgłasza Link Status: Up, diody zostają zapalone, a vSwitch trzyma uplink na liście aktywnych. Strona switcha jest czysta, jego port pada w momencie, kiedy odłączam.
Więc jedyne, co na tym hoście nie jest w takt, to wersja elxnet wobec firmware 11.2.1194.36.
Inna rodzina, ta sama lekcja. Para portów FC Emulex LPe31000/LPe32000, która działała nietknięta od wieków, przestała widzieć jakiekolwiek LUN-y po przejściu kernela Proxmoksa na 5.15.64, a potem 5.15.74. Okablowania i optyki nikt nie ruszał, a log mówił:
To regresja lpfc po stronie hosta, nie awaria optyczna; pojawiła się w kernelach po 5.15.60. Przypięcie starszego kernela startowego było obejściem, które utrzymało się na produkcji:
Opcjonalny kernel 5.19 też działał u tych, którym nie przeszkadzało opuszczenie gałęzi 5.15. Naprawa miała wylądować w 5.15.77, ale sam nigdy nie zebrałem się, żeby uruchomić ten build, więc traktuj to jako pogłoskę. Sedno zostaje: kiedy link, który wcześniej działał, umiera zaraz po tym, jak coś zmieniło się na hoście, przeczytaj log zmian hosta, zanim podejdziesz choćby blisko transceiverów.
Dorzucam lustrzane odbicie tego, bo ćwiczy ten sam odruch. Wskaźniki to oprogramowanie, a oprogramowanie myli się w obie strony.
Na EX3400 i EX2300 jest defekt Junosa, PR1428703, gdzie diody portów SFP+ i SFP zostają ciemne, podczas gdy link naprawdę stoi i przenosi ruch. Ludzie trafiali na to, przechodząc z 15.1X53 na gałęzie 18.1 i 19.x, głównie z DAC. CLI nie zgadza się z panelem:
zgłasza diodę jako Green, podczas gdy fizyczna jest zgaszona. Część buildów zgłoszono jako naprawione, a na innych ciemne diody nadal się zgłasza, więc nie nazwałbym tego czysto zamkniętym.
Twój przypadek świeci bez linku, tamten jest ciemny z linkiem. Tak czy inaczej, ufaj drugiemu końcowi i licznikom, nigdy wskaźnikowi.
Sterownik jest teraz na 11.2.1149.0 na obu hostach. Po wyjęciu kabla diody gasną, esxcli zgłasza link down, a uplink standby przejmuje tak, jak zawsze powinien - vMotion przeszedł czysto przez każdy uplink osobno jako test.
Para sterownik-firmware trafia do naszej checklisty serwisowej serwera, żeby następny pakiet znowu po cichu ich nie rozdzielił.