ESXi sieht keine LUNs von V3700 über direct attached FC

[pirx]

Hallo,

ich habe gerade ein seltsames Problem. An einem Standort mit V3700 sind Hosts per FC damit direkt verbunden. Bisher hingen 3 Fujitsu Server daran, jetzt kommt an die letzten beiden freien Ports ein neuer HPE DL380Gen10 Server mit SN1200E Adaptern. Auf der V3700 ist alles eingerichtet und die WWPNs des Hosts werden grundsätzlich gesehen. Solange der Host im BIOS steht, sind die Ports auf der V3700 "active" und man sieht sowohl das Target als auch die gemappten 4 LUNS. Sobald der Host aber ESXi bootet gehen die Ports auf der V3700 auf "inactive" und in ESXi sieht man auch keine LUNs.

Angefangen haben wir mit FW und lpfc Treibern aus dem letzten HPE SPP 2021.10. Inzwischen bin ich auch die Kombination zurück gegangen, die in der VMware CM https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=42733&deviceCategory=io&details=1&partner=515&releases=485&keyword=SN1200E%20&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc steht, inklusive mehrerer Cold Boots.

Code: Alles auswählen


# vmkchdev -l |grep vmhba2
0000:12:00.0 10df:e300 1590:0214 vmkernel vmhba2


#  esxcli storage san fc list
   Adapter: vmhba2
   Port ID: AB0200
   Node Name: 20:00:94:40:c9:ce:84:ae
   Port Name: 10:00:94:40:c9:ce:84:ae
   Speed: 8 Gbps
   Port Type: NPort
   Port State: ONLINE
   Model Description: HPE SN1200E 16Gb 2p FC HBA
   Hardware Version: 0000000c
   OptionROM Version: 12.8.352.12
   Firmware Version: 12.8.352.12
   Driver Name: lpfc
   DriverVersion: 12.8.317.0
      ..


Ich habe hier im Forum einen alten Beitrag gefunden, wo das gleiche Problem beschrieben wurde und es am Treiber lag (aber anders FC Adapter/Treiber, nicht HPE). Oder dass das Problem nach einem Host Reboot verschwunden ist. Beiden habe ich aber schon probiert.

Wenn es am Treiber läge, wie kann der aktuell verwendetet falsch sein? Die VID passt mit der aus dem VM CM überein. Was mit noch aufgefallen ist, wenn ich den Host herunterfahre, endet der Vorgang mit einem PSOD. Installiert wurde der Host mit einem aktuellen HPE ESXi 6.7 U3 Image.

Edit 1:
Habe mal das aktuelle und eine alten HPE ISO gebootet und dann geschaut, aber auch dort gibt es keinen LUNs. Auch das das fixe Einstellen der Ports auf 8 Gb/s hat nichts gebracht.

Edit 2:
VMware-VMvisor-Installer-6.7.0.update03-14320388.x86_64.iso funktioniert und zeigt die LUNs. Darin ist die lpfc Version 11.4.33.25-14vmw.670.3.73.14320388 enthalten.

Es kann doch nicht sein, dass das HPE Image einen Treiber für lpfc / Emulex enthält, der seit Monaten kaputt ist?


Edit 3:

Eigentlich funktionieren alle Treiber von der VMware Treiber Seite für 6.7 mit der aktuellen FW.

Aktuell installiert:

Firmware: 12.8.528.12
Treiber: 14.0.326.12

Laut VMware CM wäre die aktuelle zertifizierte Kombination:

Treiber: 12.8.317.0
Firmware 12.8.352.12

HPE SN1200E2P 16Gb 2p FC HBA

Laut HPE SPP:

Firmware: 12.8.528.12
Treiber: 12.8.528.14



Wie ich dieses Chaos die letzten Jahre vermisst habe...

[Dayworker]

Hinsichtlich deiner Frage, ob eine defekte Treiber-Version seit längerem enthalten sein kann, würde ich JA sagen. Kommt halt darauf an, wie häufig diese Kombi noch verkauft bzw allgemein genutzt wird.

Auffällig ist jedoch eine Treiber-Version 14.0.x, während alle anderen Listungen die Version 12.8.x vorsehen.

Was sagen denn die Best-Practices dazu?

[pirx]

Hinsichtlich deiner Frage, ob eine defekte Treiber-Version seit längerem enthalten sein kann, würde ich JA sagen. Kommt halt darauf an, wie häufig diese Kombi noch verkauft bzw allgemein genutzt wird.

Auffällig ist jedoch eine Treiber-Version 14.0.x, während alle anderen Listungen die Version 12.8.x vorsehen.

Was sagen denn die Best-Practices dazu?

Ich habe jetzt sicher 5 verschiedene lpfc Treiber von der 6.7er Treiber Seite ausprobiert. Alle von 14.0.x über 12.8.x bis runter zu 12.6.x haben mit der letzten von HPE im SPP 2021.10 Firmware funktioniert.

Die letzten beiden HPE ESXi 6.7 ISOs funktionieren mit ihren Treibern nicht, ebenso nicht der Treiber der über das SPP + asmd + sut installiert wurden (bzw. mit dem ILO Amplifier). Ich kann mir einfach nicht vorstellen, dass so bei so einem verbreiteten FC Adapter wie dem SN1200E ich der erst bin dem das auffällt.

Was Best Practice angeht, welche meinst du? VMware Compatibility Matrix? HPE SPP? Oder HPE VMware Recepie?

[Dayworker]

Der ISO-Bau erfolgt schon seit Jahren automatisiert. Es reicht daher aus, wenn eine Abhängigkeit nicht angehakt wurde und heraus kommt ein fehlerhaftes ISO. Wenn diesen Umstand niemand meldet, kennst du die Folgen.

Ausgehend von meinen Erfahrungen mit LSI-HBAs bzw deren FW-Versionen und dem Zusammenspiel mit im OS enthaltenen Treiber-Versionen, kann es selbst dabei zu unerwarteten Problemen kommen. HP bzw in dem Fall wohl HPE hatte/hat eigentlich für fast alles eine Matrix und die V3700 schient auch häufiger verwendet worden zu sein. Ich würde daher mal die Untiefen der HP/HPE-Webseiten durchsuchen und nach einer Best-Practice für deine Geräte-Kombi Ausschau zu halten. Ansonsten dürfte IBM bzw Lenovo eine weitere Anlaufstation sein, falls wir hier über eine Storwize V3700 sprechen.

[pirx]

Ja, es geht im die Storwiz V3700. Tickets bei HPE und IBM sind schon offen, aber bei HPE ist das ja immer eine Katastrophe wenn es nicht um ein astreines HW Problem geht. Und eine Best Practice zu HPE + V3700 habe ich nicht gefunden.

Es ist ja nicht so, dass die HPE ISOs den Treiber nicht haben, er funktioniert einfacht nicht. Und das auch mit älteren Versionen des ISO. Ich vermute ja immer noch ein Problem auf meiner Seite, aber ich kann es einfach nicht fassen, was ich da falsch machen könnte.

[pirx]

https://www.dell.com/support/kbdoc/en-e ... max?lwp=rt

Code: Alles auswählen

Symptoms
After updating Emulex drivers to either version 12.8.317.0 or 12.8.351.29 on ESXi 6.5 or 6.7, users report loss of connection to their arrays.

Cause
Emulex driver versions 12.8.317.0 and 12.8.351.29 for ESXi 6.5 and 6.7 are setting writeXferRdyDis irrespective of lpfc_first_burst_enable parameter. Dell Storage rejecting PRLI because B_WR_XFR_RDY_DISABLE is enabled.

Resolution
The user can choose from one of the following fixes:
A fix from Emulex is in the Emulex version 12.8.542.25 and later driver for ESXi 6.7. This driver is now available on vmware.com and is expected to be added to an upcoming Dell Customized ESXi 6.7 OS image.

Das klingt doch sehr ähnlich, auch wenn es um Dell geht. Im HPE Image sind nur ältere Versionen und die nativen VMware Versionen waren entweder älter, neuer oder genau die Version mit dem Fix.

[irix]

Kann man den Parameter als adv. Setting fuer das Module setzen oder zumind. mal angucken?

Meine Kollegen von der Schwesterfirma haben dutzende der V3xxx/5xxx..... aber wollen immer QLogic HBAs und keine Emulex.

Gruss
Joerg

[pirx]

Welchen Parameter und welchen Wert?

# esxcli system module parameters list -m lpfc | grep lpfc_first_burst_enable
lpfc_first_burst_enable int Enable First burst for Targets that support first burst

Wenn ich den KB richtig verstehe, dann wird writeXferRdyDis gesetzt, unabhängig vom Wert für lpfc_first_burst_enable.

Jetzt geht es ja darum die passende Treiberversion zu wählen, bis HPE/IBM da was definitive dazu sagen wird einige Zeit vergehen. Es gibt ja einige Versionen die funktionieren, nur ist keine davon offiziell unterstützt.

[pirx]

Kurzes Update: nach > 1 Woche ohne Rückmeldung vom HPE Support wurden jetzt nochmal Logs angefragt, nach dem ich mich nach dem aktuellen Status erkundigt habe. VMware Support verweist auf HPE da es sich um Async Treiber handelt. Ich war ja einige Jahre nicht mehr so tief in dem Thema, es hat sich leider wenig geändert, wenn man in dem Bereich Probleme hat, wird's zäh.

Wir haben zwar eine Treiber/FW Kombination wo die Storage Pfade gesehen werden, aber jeder Reboot/Shutdown endet mit einem PSOD in dem etwas zum lpfc driver steht. Und das bei praktisch alle Treiberversionen. Ein Dump wird leider weder auf die lokale dump location noch nach netdump geschrieben, wahrscheinlich weil zu dem Zeitpunkt die wichtigen Treiber schon entladen sind. Ich muss mal schauen ob ich das über Seriell + ILO irgendwie bekomme.

[pirx]

Bisher keine Lösung für den PSOD. HPE hat uns zu den Treibern und FWs direkt von Broadcom verwiesen, aber am PSOD ändert das auch nichts. Auch der Tausch der Adapter hat nichts geändert.

Interessant ist die Aussage von HPE, dass seit einigen Jahren die Storagehersteller die Zertifizierung für Adapter + Treiber + FW vorgeben. Im IBM SSIC Tool findet man dann zu dem HPE SN1200E Adapter praktisch kein Storage von IBM das unterstützt wird. Noch besser ist, dass sich das Ergebnis unterscheidet, wenn man das Dual Port Adapter mit gleichem Chipsatz wählt, oder gleiche das Emulex Adapter LPe31000-M6. Oder Adapter von anderen Herstellern mit dem gleichen Chipsatz.

[Dayworker]

Die meisten Adapter sind eher Bohnenstroh, ohne Firmware machen die fast garnix mehr. Die FW wird entweder per Treiber geladen oder bei der Initialisierung lädt der Adapter die FW aus seinem eingebauten Flashspeicher. Vorteil dessen ist natürlich, daß sich auftretende Fehler recht leicht/zeitnah nachträglich per SW beseitigen lassen und die HW nur noch bei grösseren Problemen ausgetauscht werden muß. Vom steinalten LSI2008 ist beispielsweise bekannt, daß nicht jede FW mit jeder Treiberversion zusammenspielt(e). Von daher schockiert die Aussage von HPE im Grunde nicht wirklich, sorgt jedoch bei Problemen für unerwartete, zusätzliche Kompexität.

[pirx]

HPE möchte dann wohl keine Server mehr verkaufen. Wenn die Komptabilität für alle anderen Storages als von HPE, durch den jeweiligen Storagehersteller kommen muss. Diese Listen sind doch nie vollständig und welches Interesse hätte IBM da viel Zeit für HPE Server reinzustecken. Der HPE Support zeigt wegen des bekannten lpfc Treiberproblems auch auf Broadcom, bzw. works-for-HPE-Storage. Das bedeutet für uns, dass HPE Server am Ende nicht in einer heterogenen Umgebung eingesetzt werden können.

[Dayworker]

Doch sie wollen und werden Server verkaufen. Viele Kunden beschäftigen sich aber vielleicht überhaupt nicht mehr mit reiner HW, sondern kaufen eine bestimmte Dienstleistung gewissermaßen als Blackbox ein und wie die nachher aufgebaut ist, bleibt Problem des Dienstleisters. Es ist also durchaus vorstellbar, daß eure Kombi mit Direct Attached FC-Storage zwar superperformant, sich aber am Ende für die Nutzermehrheit als zu unflexibel herausgestellt hat. Werden Kombis nicht mehr so stark angefragt, sparen sich alle Beteiligten Zeit und im Endeffekt viel Geld für den Zertifizierungsprozeß. Sowas könnte dann auf ein Anbieter-PingPong hinauslaufen, bei dem nur keiner zugeben will, daß sich der Nutzer in Richtung Sackgasse bewegt. Genauso vorstellbar wäre, daß sich ähnlich gelagerte Probleme irgendwann auch im Zusammenspiel mit anderen Server-Herstellern zeigen. Die EW steht ja nicht still und Storages übernehmen inzwischen auch viele Aufgaben eigenständig.
Unser "irix" hatte pragmatisch QLogic-HBAs genannt. Was spricht dagegen diese auszuprobieren, anstatt auf eine wie auch immer geartete Lösung in der Zukunft zu hoffen?

[pirx]

Es gibt hier den Standard Emulex bei FC zu verwenden. Ich sehe auch nicht was das ändern würde. Das grundsätzliche Problem ist für mich, dass auf den Storage Hersteller verwiesen wird, auch wenn der PSOD für den Treiber des FC Adapter auftritt.

Es gibt genau 0 Adapter von HPE für ESXi in der SSIC Liste von IBM für die V3700 und VMware. Es gibt exakt einen uralten HP 82Q Adapter der für die V3700 von IBM zertifiziert ist, und das nur für Win Server 2016. An anderen Standorten verwenden wir den IBM SVC, auch da sieht es in der Liste nicht besser aus. Wenn HPE sich also aus der Verantwortung zieht und ausschließlich auf den Storagehersteller zeigt, dann ist das für mich als Kunden ein eindeutiges Zeichen. HPE sollte ja ein eigenes Interesse haben, dass ihre Server auch mit anderen Systemen zusammenarbeiten. Das es dabei immer mal zu Problemen kommen kann ist mir bewusst.

[pirx]

Der VMware inbox Treiber 11.4.33.26-14vmw für 6.7U3 funktioniert ohne PSOD. Keine Emulex async Treiber aus den Reihen 12.x, 14.x funktioniert ohne PSOD. Der 11er hilft aber nur begrenzt weil aktuell die ganz große Debatte los getreten wurde, welcher Hersteller die Kompatibilität Storage V3700 <-> HBA vorgibt. Wenn wir nach dem HPE recipe für VMware / SPP gehen, wären wir bei einem 12.8er Treiber.

- Broadcom sagt ja: https://docs.broadcom.com/doc/elx_DRVVM-RN12811-101.pdf
- HPE verweist auf IBM (auch wenn Broadcom für ihre OEM Karten - also auch die von HPE - die V3700 angibt, s.o.)
- IBM sagt in SSIC Matrix nein, aber an anderer Stelle, dass SSIC Matrix nicht mehr gepflegt wird und veraltet ist
- VMware sagt jein: Storwize V3700
- in der VMware List ist die V3700 als Typ 2145 enthalten, das wäre aber SVC. Außerdem ist das eine ziemliches Versionschaos, manche Versionen stehen mit 16G direct attached drin, soweit ich weiß gibt es aber keine 16G V3700. Für SW Version 7.8 und 8G direct attached ist aber gar nichts drin.

Das wäre mit Qlogic nicht anders, weil auch dafür das Chaos nicht anders ist.

[pirx]

Da IBM zugibt unsere Konfiguration nicht getestet zu haben und darauf verweist aus den unterschiedlichen Listen die Schnittmenge zu suchen, verwenden wir jetzt den Treiber 11.4.33.26-14vmw. Immer in der Hoffnung das es kein neues Problem gibt, weil dieser Treiber von HPE ja wiederum nicht unterstützt wird. Sprich: wenn wir ein neues Problem haben und einen Case bei HPE dafür eröffnen müssen, wird wieder der Hinweis kommen, dass wir auf eine passende Version gehen sollen. Dann geht die Eskalation wieder von vorne los.

[irix]

Wenn denn irgendwann alles mal in der Cloud ist dann sind das Probleme der vergangenen Tage

Gruss
Joerg

[irix]

Fuer v5000/7000 gilt bei IBM gerade. K.a ob die v3700 nicht auch betroffen ist.

Code: Alles auswählen

Hosts with Emulex 16Gbps HBAs may become unable to communicate with a system with 8Gbps Fibre Channel ports, after the host HBA is upgraded to firmware version 12.8.364.11. This does not apply to systems with 16Gb or 32Gb Fibre Channel ports (hide details)
Symptom    Loss of Access to Data
Environment    Systems with 8Gbps Fibre Channel ports
Trigger    Host Emulex 16Gbps HBA is upgraded to firmware version 12.8.364.11
Workaround    Do not upgrade host HBA to firmware version 12.8.364.11

Gruss
Joerg

[irix]

Pruefen ob DirectAttached mittels 16G FC <-> 8G SAN bei IBM supportet ist(Meine Kollegen sagen "nein"). Das ist nur supportet fuer/bis 8GB FC.

Gruss
Joerg