Optyka QLE2692 łączy się, ale Proxmox VE 6.2 nie pokazuje żadnych LUN-ów: qla2xxx register_localport failed
Przenoszę parę hypervisorów na storage Fibre Channel, i jeden host odmawia pokazania choćby jednego LUN-u, podczas gdy dokładnie ten sam sprzęt działa, gdy karta jest przekazana do VM.
- QLogic QLE2692, 16/32Gb FC na bazie ISP2722, oba porty okablowane
- Fujitsu Eternus DX100 S5 po drugiej stronie
- host Proxmox VE 6.2, qla2xxx w kernelu na kernelu 5.4
- ta sama karta przekazana przez passthrough do VM z Windows na tym samym hoście
Na hoście porty wstają i optyka pokazuje światło, ale żadne urządzenia blokowe się nie pojawiają. dmesg ma to za każdym razem, gdy sterownik się inicjalizuje:
qla2xxx: register_localport failed: ret=ffffffea
WARNING in qla_nvme_register_hbaCo już zrobiłem:
- zamieniłem moduły SFP+ i patchcordy między dwoma portami, bez żadnej zmiany
- przekazałem całą kartę przez passthrough do VM z Windows: LUN-y DX100 pojawiają się tam natychmiast, więc okablowanie, optyka i strona macierzy są wyraźnie w porządku
- sprawdziłem
lspci -k, qla2xxx jest podpięty do obu funkcji i nic innego nie walczy o kartę
Nawet nie próbuję tu uruchomić NVMe po FC, chcę po prostu zwykłych LUN-ów FC na hoście. Czy warto dalej rozbierać optykę, czy to jest jednoznacznie problem sterownika hosta?
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 5
Zanim znowu dotkniesz optyki, wyłóż na stół nudne szczegóły. Wklej cały blok dmesg zamiast tych dwóch linii: wszystko, co sterownik wypisuje od probe w dół, aż do ostrzeżenia włącznie. Sama linia rejestracji nikomu nie mówi, czy porty skończyły wstawanie, czy padły w połowie inicjalizacji.
I powiedz, czy macierz w ogóle prezentuje cokolwiek jako namespace'y NVMe, czy tylko zwykłe LUN-y SCSI. Komunikat, który wkleiłeś, wychodzi z połowy sterownika odpowiadającej za NVMe, więc jeśli nigdzie w tej konfiguracji nie ma namespace'ów, to już zawęża, co zawodzi i dlaczego reszta stosu idzie za tym.
Nigdzie żadnych namespace'ów: macierz serwuje wyłącznie zwykłe LUN-y SCSI FC, nic w tym fabric nie mówi NVMe, i właśnie dlatego ten komunikat od początku wydawał mi się dziwny.
Blok dmesg jest krótki i nudny. Sterownik się ładuje, obie funkcje probe'ują się czysto, porty wstają, a potem ląduje
register_localport failed: ret=ffffffea, zWARNING in qla_nvme_register_hbazaraz za nim. Żadnych timeoutów, żadnych resetów, nic o fabric pomiędzy. Powtarza się dla obu portów przy każdym pojedynczym boocie, i po tym na hoście nie pojawia się ani jedno urządzenie SCSI. Ta sama karta z tymi samymi modułami w VM z passthrough widzi LUN-y od razu.Przestań patrzeć na transceivery, to sterownik hosta. qla2xxx w kernelu na 5.4 zawodzi przy rejestracji NVMe-FC podczas stawiania adaptera, co jest dokładnie tym
register_localport failed: ret=ffffffea, jakie widzisz, i to zostawia porty FC bezużyteczne też do wszystkiego innego. Dlatego twoje zwykłe LUN-y SCSI nigdy się nie pojawiają, mimo że nigdzie nie prosiłeś o NVMe-FC. Passthrough działa, bo sterownik Windows nie ma nic wspólnego z żadnym z tego kodu.Praktyczną drogą jest inny kernel. Te same karty zachowują się dobrze na Proxmox 6.1 z kernelem 5.3, i znowu dobrze na 5.8, więc wybierz, który z nich pasuje do twoich planów aktualizacji, zbootuj go, sprawdź, czy ostrzeżenie o rejestracji zniknęło z dmesg, a potem zrób rescan. Nawyk wart wyrobienia przy HBA FC w ogóle: grepuj dmesg pod kątem błędów po stronie sterownika, zanim podejrzewasz moduł, bo sterownik, który umiera przy inicjalizacji, wygląda dokładnie jak martwy link, kiedy wpatrujesz się w macierz storage.
To było to. Zbootowałem 5.8 na hoście, ostrzeżenie o rejestracji zniknęło z dmesg, a LUN-y DX100 wyliczyły się na obu ścieżkach bez żadnych dalszych zmian, te same kable, te same moduły, ten sam zoning. Dla kompletności postawiłem drugi node z powrotem na 6.1 z kernelem 5.3 i tam też działa, więc awaria naprawdę jest ograniczona do 5.4 na tym sprzęcie. Karta i optyka zostają dokładnie takie, jakie są, i zostają mi zapasowe moduły, które już zamówiłem.
Potwierdzam ten wzorzec z innej strony: trafiliśmy dokładnie na to na Proxmox 7.1 pod kernelem 5.13, więc 5.4 to nie jedyny dotknięty, i warto to sprawdzać po każdej zmianie kernela.
Emulex nie jest zresztą lepszy. Dwa porty LPe31000/LPe32000, które chodziły nietknięte miesiącami, przestały widzieć jakiekolwiek LUN-y po tym, jak kernel poszedł na 5.15.64, a potem 5.15.74, z
Enable MI Mailbox x9b (x1/xbf) failed, rc:x10 mi:x2iCMF is disabledw logu, i ani jednego znalezionego targetu potem. Kable i optyka nietknięte, oczywiście. To siedzi w lpfc i przyjechało z kernelami po 5.15.60. Dwa sposoby wyjścia z tego zadziałały ludziom: przytrzymać kernel bootowy tam, gdzie jeszcze działał, przezproxmox-boot-tool kernel pin 5.15.60-2-pve, albo przeskoczyć na opcjonalny kernel 5.19, jeśli opuszczenie gałęzi 5.15 jest dla ciebie akceptowalne. Naprawa miała wylądować w 5.15.77, ale nigdy nie doszedłem do wypróbowania tego builda. Chodzi o to, że kiedy link FC wygląda na martwy zaraz po pracach serwisowych, sprawdź, w jaki kernel zbootowałeś, zanim zaczniesz zamawiać moduły na wymianę.