42
Verbindung ESXi mit NAS über Fibre Channel
Hallo zusammen,
ich bin gerade dabei, zwei ESXi-Server mit einem QNAP-NAS über FC zu verbinden. In beiden ESXi (6.7 und 7.0) ist jeweils eine Qlogic QLE-2562 und im QNAP 673 eine QLE-2662 verbaut. Im QNAP werden 2 FC-Ports angezeigt und in den ESXi nach Installation der aktuellen Treiber werden beide Adapter im Bereich Hardware-Speicheradapter angezeigt. Beide sind aber im offline-Modus. Alle Karten sind miteinander verbunden. Es gibt im ESXi-Client keine Möglichkeit, die HBA's in der GUI zu konfigurieren. Wie kriege ich die HBA's bzw. die Speicher online? Trotz intensiever Suche im Netz komme ich nicht aus die Lösung. Für einen Tipp bzw. Link zur Anleitung wäre ich dankbar.
ich bin gerade dabei, zwei ESXi-Server mit einem QNAP-NAS über FC zu verbinden. In beiden ESXi (6.7 und 7.0) ist jeweils eine Qlogic QLE-2562 und im QNAP 673 eine QLE-2662 verbaut. Im QNAP werden 2 FC-Ports angezeigt und in den ESXi nach Installation der aktuellen Treiber werden beide Adapter im Bereich Hardware-Speicheradapter angezeigt. Beide sind aber im offline-Modus. Alle Karten sind miteinander verbunden. Es gibt im ESXi-Client keine Möglichkeit, die HBA's in der GUI zu konfigurieren. Wie kriege ich die HBA's bzw. die Speicher online? Trotz intensiever Suche im Netz komme ich nicht aus die Lösung. Für einen Tipp bzw. Link zur Anleitung wäre ich dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7401849282
Url: https://administrator.de/forum/verbindung-esxi-mit-nas-ueber-fibre-channel-7401849282.html
Ausgedruckt am: 23.12.2024 um 19:12 Uhr
42 Kommentare
Neuester Kommentar
Haben die QLogic-Karten nicht ein eigenes BIOS, das man beim Booten des Servers aufrufen kann (ich glaube mit Strg+Q)?
Jürgen
Jürgen
Tatsächlich, habe ich gefunden .-)) Danke! Es gibt dort mehrere Einstellungsmöglichkeiten. Was sind die richtigen?
Guten Morgen,
https://serverfault.com/questions/591234/vmware-esxi-fiber-channel-confi ...
Habe leider so ein Setting nicht. Als HBA quasi dumm machen und dann unter ESXi verwalten ist bei vielen eine Option.
Sind die Karten an sich kompatibel ? Nach 6.7 wird es mit gebastelten Lösungen ätzend. Mit HPE Karte konnte ich so zumindest mal Eternus anbinden. Aber sehe nur eine LUN. Konnte damit leben...
Aus den Bauch raus: max. bis 6.7 als Homelab gehen. Dann sind zumindest die Chancen höher legacy Erweiterungen zu betreiben. Man kann noch tiefer hinein gehen und Anbindungen manuell nachsteuern. Ist aber mehr nur ein Mapping, wie ESXi bei Hersteller und Gerät XYZ reagieren soll.
Würde mal den HBA Modus probieren.
Ansonsten wäre es auch etwas komisch. Du hast teure Storage Devices die RAID und allen Schnickschnack können und die Karte macht dann wiederum ggf. nochmal einen RAID und stellt ein Volume zu Verfügung. Durch die Brust ins Auge. Möchte wetten mit HBA wirst du da mehr Glück haben.
https://www.marvell.com/support/downloads.html
https://serverfault.com/questions/591234/vmware-esxi-fiber-channel-confi ...
Habe leider so ein Setting nicht. Als HBA quasi dumm machen und dann unter ESXi verwalten ist bei vielen eine Option.
Sind die Karten an sich kompatibel ? Nach 6.7 wird es mit gebastelten Lösungen ätzend. Mit HPE Karte konnte ich so zumindest mal Eternus anbinden. Aber sehe nur eine LUN. Konnte damit leben...
Aus den Bauch raus: max. bis 6.7 als Homelab gehen. Dann sind zumindest die Chancen höher legacy Erweiterungen zu betreiben. Man kann noch tiefer hinein gehen und Anbindungen manuell nachsteuern. Ist aber mehr nur ein Mapping, wie ESXi bei Hersteller und Gerät XYZ reagieren soll.
Würde mal den HBA Modus probieren.
Ansonsten wäre es auch etwas komisch. Du hast teure Storage Devices die RAID und allen Schnickschnack können und die Karte macht dann wiederum ggf. nochmal einen RAID und stellt ein Volume zu Verfügung. Durch die Brust ins Auge. Möchte wetten mit HBA wirst du da mehr Glück haben.
https://www.marvell.com/support/downloads.html
1
Es sit kein eigenes BIOS. Ich komme zu den Einstellungen über das BIOS des Servers über System configuration. (HP Proliant DL380). Das Aktivieren von Hardloop ID und unter Boot settings Adapter Driver auf Enabled gestellt: reicht anscheinend nicht. Sollte Hardloop ID noch geändert werden (aktuell steht 0)?
Hab mir die Karte mal angschaut. HBA sollte soweit passen.
Gibt auch Treiber für 6.7/ 7.x
https://kb.vmware.com/s/article/1003680
Was ist mit der anderen Seite? LUN Settings an den QNAP?
Treiber
Würde Treiber mal kontrollieren. Welchen Patchstand haben die Hypervisoren? Immen den letzten?
ESXi bietet Diagnose Tools. Das wär mit der 1. Anlaufpunkt.
Ansonsten könntest du die Karte Testweise unter Windows testen und schauen ob die LUNs ankommen.
Was ist mit Sicherheit? Darf der ESXi auf die LUN zugreifen? Meist muss man noch die ID hinterlegen. Weiss nicht wie es bei Qnap ist.
Ggf. darf sich der Host nicht verbinden, da die Karte nicht auf den Qnap hinterlegt ist?
Ist die Konfiguration auf den Qnap wirlich so OK ? LUN FC-Port-Mapping?
Gibt auch Treiber für 6.7/ 7.x
https://kb.vmware.com/s/article/1003680
Was ist mit der anderen Seite? LUN Settings an den QNAP?
Treiber
Würde Treiber mal kontrollieren. Welchen Patchstand haben die Hypervisoren? Immen den letzten?
ESXi bietet Diagnose Tools. Das wär mit der 1. Anlaufpunkt.
Ansonsten könntest du die Karte Testweise unter Windows testen und schauen ob die LUNs ankommen.
Was ist mit Sicherheit? Darf der ESXi auf die LUN zugreifen? Meist muss man noch die ID hinterlegen. Weiss nicht wie es bei Qnap ist.
Ggf. darf sich der Host nicht verbinden, da die Karte nicht auf den Qnap hinterlegt ist?
Ist die Konfiguration auf den Qnap wirlich so OK ? LUN FC-Port-Mapping?
Der QNAP erkennt die qle-2662 und zeigt 2 Ports. Ich habe die WWN's der QLE-2562 von den beiden ESXi manuell für beide Ports eingetragen und eine LUN für FC erstellt. Die Optionen LUN-Masking und LUN-Zuordnung bearbeiten sind ausgegraut. Die LUN ist im FC-Speicher sichtbar und aktiviert. Im Status der Karte im QNAP steht: Trennen, Initiatoren: 0. Alle 3 LED's der Karte am QNAP leuchten durchgehend, an den ESXi's blinken alle 3. Trotz Aktivierung im BIOS steht die Karte immer noch unter Adapters im ESXi auf offline. DIe Treiber für die Karten von der Seite der ESXi's sind aktuell. Versuche noch die Karte über Passthroug an eine Windows VM weiterzuleiten. Sonst weiss ich nicht weiter. Die Karten von den ESXi's sind mit jeweils einem Port an den QNAP angeschlossen und mit dem Anderen an einen Juniper EX2200-Switch.
Moin,
Mal ne blöde Frage:
Die Verkabelung ist korrekt?
Als TX am ESXi geht auf RX am QNAP HBA?
Sprich, die einzelnen LWL-Fasern werden gekreuzt?
Und die Qlogic im QNAP ist auch tatsächlich supported? Im WWW stolpert man gelegentlich drüber, dass die Karte zwar supported ist, wenn die aber ein HP (oder anderes) Branding hat, kann das problematisch sein…
Mal ne blöde Frage:
Die Verkabelung ist korrekt?
Als TX am ESXi geht auf RX am QNAP HBA?
Sprich, die einzelnen LWL-Fasern werden gekreuzt?
Und die Qlogic im QNAP ist auch tatsächlich supported? Im WWW stolpert man gelegentlich drüber, dass die Karte zwar supported ist, wenn die aber ein HP (oder anderes) Branding hat, kann das problematisch sein…
2
Adapter rescan und mal log file posten? Ggf. bringt uns das weiter. Nach jeden scan sieht man die frischen Ergebnisse.
Logs
vmkernel.log sollte nach Rescan was am Ende liefern... Oder auch mal die Zwischenmeldungen da checken....
Logs
vmkernel.log sollte nach Rescan was am Ende liefern... Oder auch mal die Zwischenmeldungen da checken....
Ich akonnte gestern nicht weitermachen und bin erst spät wiedergekommen. Habe die Verkabelung gecheckt.
Ich weiß nicht, was man da falsch machen kann. Die Kabel passen zum Transceiver. Der eine Port der QLE-2562 ist jeweils mit dem Port des QLE-2662 im QNAP verbunden. Der Andere mit dem Juniper Switch.
Zitat von @em-pie:
Moin,
Mal ne blöde Frage:
Die Verkabelung ist korrekt?
Als TX am ESXi geht auf RX am QNAP HBA?
Sprich, die einzelnen LWL-Fasern werden gekreuzt?
Und die Qlogic im QNAP ist auch tatsächlich supported? Im WWW stolpert man gelegentlich drüber, dass die Karte zwar supported ist, wenn die aber ein HP (oder anderes) Branding hat, kann das problematisch sein…
Moin,
Mal ne blöde Frage:
Die Verkabelung ist korrekt?
Als TX am ESXi geht auf RX am QNAP HBA?
Sprich, die einzelnen LWL-Fasern werden gekreuzt?
Und die Qlogic im QNAP ist auch tatsächlich supported? Im WWW stolpert man gelegentlich drüber, dass die Karte zwar supported ist, wenn die aber ein HP (oder anderes) Branding hat, kann das problematisch sein…
Ich weiß nicht, was man da falsch machen kann. Die Kabel passen zum Transceiver. Der eine Port der QLE-2562 ist jeweils mit dem Port des QLE-2662 im QNAP verbunden. Der Andere mit dem Juniper Switch.
Zitat von @Crusher79:
Adapter rescan und mal log file posten? Ggf. bringt uns das weiter. Nach jeden scan sieht man die frischen Ergebnisse.
Logs
vmkernel.log sollte nach Rescan was am Ende liefern... Oder auch mal die Zwischenmeldungen da checken....
Adapter rescan und mal log file posten? Ggf. bringt uns das weiter. Nach jeden scan sieht man die frischen Ergebnisse.
Logs
vmkernel.log sollte nach Rescan was am Ende liefern... Oder auch mal die Zwischenmeldungen da checken....
Hier ist der vmkernel.log nach einem rescan und einpaar andere Bilder.
2023-06-04T07:22:01.410Z cpu31:2218891)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:22:34.948Z cpu38:2099118 opID=515e)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:22:34.948Z cpu38:2099118 opID=515e)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:22:36.727Z cpu34:2101483 opID=4fcb0eca)World: 12075: VC opID esxui-28f7-c209 maps to vmkernel opID 4fcb0eca
2023-06-04T07:22:36.727Z cpu34:2101483 opID=4fcb0eca)NVDManagement: 1672: No nvdimms found on the system
2023-06-04T07:23:35.067Z cpu39:2099118 opID=e06e)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:23:35.067Z cpu39:2099118 opID=e06e)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:24:01.413Z cpu43:2219028)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:24:35.188Z cpu46:2099118 opID=2433)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:24:35.188Z cpu46:2099118 opID=2433)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:25:35.299Z cpu54:2099118 opID=6e04)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:25:35.299Z cpu54:2099118 opID=6e04)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:26:01.418Z cpu25:2219295)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:26:22.480Z cpu16:2097584)StorageDevice: 7059: End path evaluation for device naa.600508b1001c103ebc13fe61c2bbba3f
2023-06-04T07:26:22.481Z cpu16:2097584)StorageDevice: 7059: End path evaluation for device naa.6e843b6e347c4b1d7270d40f3dab4edd
2023-06-04T07:26:22.482Z cpu16:2097584)StorageDevice: 7059: End path evaluation for device naa.600508b1001c42c2cf3ebe6da9aa588b
2023-06-04T07:26:22.482Z cpu16:2097584)StorageDevice: 7059: End path evaluation for device naa.6e843b6205a0805d1747d4490db8ded7
2023-06-04T07:26:22.483Z cpu16:2097584)StorageDevice: 7059: End path evaluation for device naa.600508b1001c1ca2f4e2877436510aad
2023-06-04T07:26:22.483Z cpu16:2097584)StorageDevice: 7059: End path evaluation for device naa.600508b1001c856db30d28a1b72e6be2
2023-06-04T07:26:22.484Z cpu16:2097584)StorageDevice: 7059: End path evaluation for device naa.6e843b659ccead1d7407d4069da1eed7
2023-06-04T07:26:22.484Z cpu16:2097584)StorageDevice: 7059: End path evaluation for device naa.6e843b6cd4d7600d7cbbd41fad8d90d2
2023-06-04T07:26:35.418Z cpu14:2219396)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:27:35.538Z cpu36:2099118 opID=f472)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:27:35.538Z cpu36:2099118 opID=f472)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:28:01.423Z cpu1:2219446)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:28:35.647Z cpu62:2099118 opID=4107)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:28:35.647Z cpu62:2099118 opID=4107)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:29:35.758Z cpu36:2099118 opID=d94c)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:29:35.758Z cpu36:2099118 opID=d94c)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:29:41.304Z cpu62:2101197 opID=23bc0223)World: 12075: VC opID esxui-d78f-c5d1 maps to vmkernel opID 23bc0223
2023-06-04T07:29:41.304Z cpu62:2101197 opID=23bc0223)NVDManagement: 1672: No nvdimms found on the system
2023-06-04T07:29:55.874Z cpu31:2098465)iscsi_vmk: iscsivmk_ConnNetRegister:1898: socket 0x4317998546b0 network resource pool netsched.pools.persist.iscsi associated
2023-06-04T07:29:55.874Z cpu31:2098465)iscsi_vmk: iscsivmk_ConnNetRegister:1926: socket 0x4317998546b0 network tracker id 298742206 tracker.iSCSI.192.168.XXX.XXX associated
2023-06-04T07:29:55.874Z cpu31:2098465)iscsi_vmk: iscsivmk_ConnNetRegister:1898: socket 0x4317998583f0 network resource pool netsched.pools.persist.iscsi associated
2023-06-04T07:29:55.874Z cpu31:2098465)iscsi_vmk: iscsivmk_ConnNetRegister:1926: socket 0x4317998583f0 network tracker id 298742206 tracker.iSCSI.192.168.XXX.XXX associated
2023-06-04T07:29:55.890Z cpu1:2098386)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic:476: vmhba64:CH:0 T:2 CN:0: Failed to receive data: Connection closed by peer
2023-06-04T07:29:55.890Z cpu1:2098386)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic:484: Sess [ISID: TARGET: (null) TPGT: 0 TSIH: 0]
2023-06-04T07:29:55.890Z cpu1:2098386)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic:485: Conn [CID: 0 L: 192.168.XXX.XXX:51547 R: 192.168.XXX.XXX:3260]
2023-06-04T07:29:55.890Z cpu1:2098386)iscsi_vmk: iscsivmk_ConnRxNotifyFailure:1236: vmhba64:CH:0 T:2 CN:0: Connection rx notifying failure: Failed to Receive. State=Bound
2023-06-04T07:29:55.890Z cpu1:2098386)iscsi_vmk: iscsivmk_ConnRxNotifyFailure:1237: Sess [ISID: TARGET: (null) TPGT: 0 TSIH: 0]
2023-06-04T07:29:55.890Z cpu1:2098386)iscsi_vmk: iscsivmk_ConnRxNotifyFailure:1238: Conn [CID: 0 L: 192.168.XXX.XXX:51547 R: 192.168.XXX.XXX:3260]
2023-06-04T07:29:56.143Z cpu31:2098465)WARNING: iscsi_vmk: iscsivmk_StartConnection:919: vmhba64:CH:0 T:3 CN:0: iSCSI connection is being marked "ONLINE"
2023-06-04T07:29:56.143Z cpu31:2098465)WARNING: iscsi_vmk: iscsivmk_StartConnection:920: Sess [ISID: 00023d000001 TARGET: iqn.2005-10.org.freenas.ctl:ssd340 TPGT: 1 TSIH: 0]
2023-06-04T07:29:56.143Z cpu31:2098465)WARNING: iscsi_vmk: iscsivmk_StartConnection:921: Conn [CID: 0 L: 192.168.XXX.XXX:27358 R: 192.168.XXX.XXX:3260]
2023-06-04T07:29:56.144Z cpu31:2098465)WARNING: iscsi_vmk: iscsivmk_StopConnection:738: vmhba64:CH:0 T:2 CN:0: iSCSI connection is being marked "OFFLINE" (Event:2)
2023-06-04T07:29:56.144Z cpu31:2098465)WARNING: iscsi_vmk: iscsivmk_StopConnection:739: Sess [ISID: TARGET: (null) TPGT: 0 TSIH: 0]
2023-06-04T07:29:56.144Z cpu31:2098465)WARNING: iscsi_vmk: iscsivmk_StopConnection:740: Conn [CID: 0 L: 192.168.:51547 R: 192.168.XXX,XXX:3260]
2023-06-04T07:30:01.428Z cpu0:2219589)osfs: OSFS_GetMountPointList:3726: mountPoints[0] inUse pid [ vsan], cid 5225e30a3d4f6a83-ceb3c46b4fa8bf3a
2023-06-04T07:30:04.049Z cpu19:2098383)NMP: nmp_ThrottleLogForDevice:3867: Cmd 0xa3 (0x45da33716e08, 0) to dev "Unregistered Device" on path "vmhba64:C0:T3:L1" Failed:
2023-06-04T07:30:04.049Z cpu19:2098383)NMP: nmp_ThrottleLogForDevice:3875: H:0x0 D:0x2 P:0x0 Valid sense data: 0x6 0x29 0x1. Act:NONE. cmdId.initiator=0x4538d5b1bc38 CmdSN 0x0
2023-06-04T07:30:04.049Z cpu51:2097956)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:706: Path (vmhba64:C0:T3:L1) command 0xa3 failed with transient error status Transient storage condition, suggest retry. sense data: 0x6 0x29 0x1. Waiting for 20 seconds $
2023-06-04T07:30:04.050Z cpu51:2097956)StorageApdHandler: 966: APD Handle Created with lock[StorageApd-0x4306ff3324d0]
2023-06-04T07:30:04.050Z cpu51:2097956)PsaStorEvents: 676: Event Subsystem: Device Events, Created!
2023-06-04T07:30:04.050Z cpu51:2097956)PsaStorEvents: 676: Event Subsystem: Device Events - Internal, Created!
2023-06-04T07:30:04.051Z cpu51:2097956)VMWARE SCSI Id: Id for vmhba64:C0:T3:L1
0x30 0x30 0x35 0x30 0x35 0x36 0x61 0x38 0x32 0x36 0x36 0x31 0x30 0x30 0x30 0x00 0x69 0x53 0x43 0x53 0x49 0x20
2023-06-04T07:30:04.052Z cpu51:2097956)ScsiDeviceIO: 9649: QErr is correctly set to 0x0 for device naa.6589cfc000000682ead55f321e44e852.
2023-06-04T07:30:04.052Z cpu19:2098383)NMP: nmp_ThrottleLogForDevice:3867: Cmd 0x15 (0x45da33716e08, 0) to dev "naa.6589cfc000000682ead55f321e44e852" on path "vmhba64:C0:T3:L1" Failed:
2023-06-04T07:30:04.052Z cpu19:2098383)NMP: nmp_ThrottleLogForDevice:3875: H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x1a 0x0. Act:NONE. cmdId.initiator=0x4306ff3326c0 CmdSN 0x10c98
2023-06-04T07:30:04.052Z cpu19:2098383)ScsiDeviceIO: 4161: Cmd(0x45da33716e08) 0x15, CmdSN 0x10c98 from world 0 to dev "naa.6589cfc000000682ead55f321e44e852" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x1a 0x0
2023-06-04T07:30:04.052Z cpu51:2097956)WARNING: ScsiDeviceIO: 10045: SITPUA set to 0 for device naa.6589cfc000000682ead55f321e44e852. This may cause log spam. The system was unable to change this setting to 1. Failure
2023-06-04T07:30:04.055Z cpu51:2097956)PsaStorEvents: 407: EventSubsystem: Device Events, Event Mask: 6, Parameter: 0x4306ff3ec110, Registered!
2023-06-04T07:30:04.055Z cpu51:2097956)PsaStorEvents: 407: EventSubsystem: Device Events, Event Mask: 5, Parameter: 0x4306ff3326c0, Registered!
2023-06-04T07:30:04.055Z cpu51:2097956)PsaStorEvents: 407: EventSubsystem: Device Events, Event Mask: 9, Parameter: 0x4306ff4c82a0, Registered!
2023-06-04T07:30:04.055Z cpu51:2097956)PsaStorEvents: 407: EventSubsystem: Device Events, Event Mask: 8, Parameter: 0x4306ff4739d0, Registered!
2023-06-04T07:30:04.055Z cpu51:2097956)PsaStorEvents: 407: EventSubsystem: Device Events, Event Mask: 7, Parameter: 0x4306ff4f1ba0, Registered!
2023-06-04T07:30:04.055Z cpu51:2097956)PsaStorEvents: 407: EventSubsystem: Device Events, Event Mask: d, Parameter: 0x4306ff4bdde0, Registered!
2023-06-04T07:30:04.055Z cpu51:2097956)PsaStorEvents: 407: EventSubsystem: Device Events, Event Mask: 1, Parameter: 0x4306ff45b600, Registered!
2023-06-04T07:30:04.055Z cpu51:2097956)ScsiDevice: 4797: Successfully registered device "naa.6589cfc000000682ead55f321e44e852" from plugin "NMP" of type 0
2023-06-04T07:30:04.056Z cpu51:2097956)NMP: nmp_DeviceUpdateProtectionInfo:748: Set protection info for device 'naa.6589cfc000000682ead55f321e44e852', Enabled: 0 ProtType: 0x0 Guard: 0x0 ProtMask: 0x0
2023-06-04T07:30:04.056Z cpu51:2097956)PsaStorEvents: 407: EventSubsystem: Device Events, Event Mask: b, Parameter: 0x4306ff3e1020, Registered!
2023-06-04T07:30:04.056Z cpu51:2097956)PsaStorEvents: 407: EventSubsystem: Device Events, Event Mask: c, Parameter: 0x4306ff48f8c0, Registered!
2023-06-04T07:30:04.445Z cpu30:2098465)iscsi_vmk: iscsivmk_ConnNetRegister:1898: socket 0x4317998595a0 network resource pool netsched.pools.persist.iscsi associated
2023-06-04T07:30:04.445Z cpu30:2098465)iscsi_vmk: iscsivmk_ConnNetRegister:1926: socket 0x4317998595a0 network tracker id 298742206 tracker.iSCSI.192.168.XXX.XXX associated
2023-06-04T07:30:04.462Z cpu26:2098386)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic:476: vmhba64:CH:0 T:2 CN:0: Failed to receive data: Connection closed by peer
2023-06-04T07:30:04.462Z cpu26:2098386)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic:484: Sess [ISID: TARGET: (null) TPGT: 0 TSIH: 0]
2023-06-04T07:30:04.462Z cpu26:2098386)WARNING: iscsi_vmk: iscsivmk_ConnReceiveAtomic:485: Conn [CID: 0 L: 192.168.XXX.XXX:49471 R: 192.168.XXX.XXX:3260]
2023-06-04T07:30:04.462Z cpu26:2098386)iscsi_vmk: iscsivmk_ConnRxNotifyFailure:1236: vmhba64:CH:0 T:2 CN:0: Connection rx notifying failure: Failed to Receive. State=Bound
2023-06-04T07:30:04.462Z cpu26:2098386)iscsi_vmk: iscsivmk_ConnRxNotifyFailure:1237: Sess [ISID: TARGET: (null) TPGT: 0 TSIH: 0]
2023-06-04T07:30:04.462Z cpu26:2098386)iscsi_vmk: iscsivmk_ConnRxNotifyFailure:1238: Conn [CID: 0 L: 192.168.XXX.XXX:49471 R: 192.168.XXX.XXX:3260]
2023-06-04T07:30:04.714Z cpu30:2098465)WARNING: iscsi_vmk: iscsivmk_StopConnection:738: vmhba64:CH:0 T:2 CN:0: iSCSI connection is being marked "OFFLINE" (Event:2)
2023-06-04T07:30:04.714Z cpu30:2098465)WARNING: iscsi_vmk: iscsivmk_StopConnection:739: Sess [ISID: TARGET: (null) TPGT: 0 TSIH: 0]
2023-06-04T07:30:04.714Z cpu30:2098465)WARNING: iscsi_vmk: iscsivmk_StopConnection:740: Conn [CID: 0 L: 192.168.XXX.XXX:49471 R: 192.168.XXX.XXX:3260]
Moin,
Du missverstehst nicht, bzgl. Der LWL-Kabel.
Du hast bei LWL i.d.R zwei Fasern innerhalb eines Kabels: dabei wird das Licht (bei dir) vom HBA1-TX zum HBA2-RX übertragen und vom HBA2-TX zum HBA1-RX
Wenn du aber dein Kabel nicht geprüft hast, kann es schon mal passieren, dass TX auf TX geht und RX auf RX. Dann senden beide, können aber nichts empfangen.
Hier mal ein Bild, wie es sein müsste: https://amzn.eu/d/akCEUuH
Das ist wie auf einer Straße: Autos fahren (im Rechtsverkehr) immer rechts in jede Richtung. Willst du also von A nach B fahren nutzt du die eine Spur. Sollen gleichzeitig Fahrzeuge von B nach A fahren, dann wird die andere Spur genutzt. Wollen beide aber diese eine Spur nutzen, knallt es…
Edit: da dein QNAP aber die WWNs der ESXi erkannt hat, passt deine Verkabelung aber scheinbar.
Pack dein Auszug aus dem Log mal bitte in die Code-Tags. Danke
Du missverstehst nicht, bzgl. Der LWL-Kabel.
Du hast bei LWL i.d.R zwei Fasern innerhalb eines Kabels: dabei wird das Licht (bei dir) vom HBA1-TX zum HBA2-RX übertragen und vom HBA2-TX zum HBA1-RX
Wenn du aber dein Kabel nicht geprüft hast, kann es schon mal passieren, dass TX auf TX geht und RX auf RX. Dann senden beide, können aber nichts empfangen.
Hier mal ein Bild, wie es sein müsste: https://amzn.eu/d/akCEUuH
Das ist wie auf einer Straße: Autos fahren (im Rechtsverkehr) immer rechts in jede Richtung. Willst du also von A nach B fahren nutzt du die eine Spur. Sollen gleichzeitig Fahrzeuge von B nach A fahren, dann wird die andere Spur genutzt. Wollen beide aber diese eine Spur nutzen, knallt es…
Edit: da dein QNAP aber die WWNs der ESXi erkannt hat, passt deine Verkabelung aber scheinbar.
Pack dein Auszug aus dem Log mal bitte in die Code-Tags. Danke
OK. Ich gebe zu, in Sachen FC bin ich ein absoluter Neuling. Die FC-Kabel sehen aber so aus ( s. Anhang) Es ist ein LWL Patchkabel LC LC Duplex Jumper OM3 Faser multimode Glasfaserkabel. Die Adern sind gepaart und man kann es nicht anders einstecken.
Ist in der Log-Datei der Grund zu sehen? Ich sehe da nur Bahnhof.
PS: Die WWN's wurden vom QNAP nicht automatisch erkannt, sondern manuell eingefügt.
Das mit den WWNs und den manuellen Einträgen ist schon mal gut zu wissen. Dann scheint die Hardware sich nicht zu sehen…
Dann nimm mal deine Handykamera zur Hand, zieh auf einer Seite das Kabel mal aus dem HBA und schaue mit der Kamera, auf welcher Faser des Kabels „Licht“ ankommt. Diese Faser muss dann im „freien“ HBA auf dem Port ankommen, wo kein Licht ist. Hinweis: das Licht ist ein Laser und man sollte nicht direkt rein schauen. Lieber über die Handykamera einen Blick drauf werfen
Sind die verbauten GBICs in den HBA denn auch passend?
Also welche GBICs sind dort verbaut? Die kann man ja mal rausnehmen und drauf schauen…
Dann nimm mal deine Handykamera zur Hand, zieh auf einer Seite das Kabel mal aus dem HBA und schaue mit der Kamera, auf welcher Faser des Kabels „Licht“ ankommt. Diese Faser muss dann im „freien“ HBA auf dem Port ankommen, wo kein Licht ist. Hinweis: das Licht ist ein Laser und man sollte nicht direkt rein schauen. Lieber über die Handykamera einen Blick drauf werfen
Sind die verbauten GBICs in den HBA denn auch passend?
Also welche GBICs sind dort verbaut? Die kann man ja mal rausnehmen und drauf schauen…
1
Die Adern sind gepaart und man kann es nicht anders einstecken.
Das ist so natürlich nicht richtig und vermutlich deinem Anfängerwissen geschuldet. 
Der hintere Teil des LC Steckers ist bekanntlich immer ein Clip der die 2 Einzelfasern (hier oben zu sehen mit rot, schwarz) zusammenhält.
Den kann man vorsichtig entfernen und dann die Fasern tauschen!
Was Kollege @em-pie oben schon richtig sagt: Es besteht bei 1:1 Patchkabel die Gefahr das die Sendefaser auf der Sendeoptik steckt und die Empfangsfaser auf der Empfangsoptik und dann kommt natürlich niemals eine Glasfaserverbindung zustande. Es muss genau andersrum sein. Ggf. musst du also die Fasern auf einer Seite einmal drehen. Der "Kameracheck" hilft hier!
@aqui wobei es auf dem Bild oben richtig aussieht.
ROT rechts / links.
Farben sind aber auch so eine Sache. Der Marker mit A/B weiter unte in gelb sollte ggf. mal geprüft werden.
@dbox3 Eine Sende-/ Empfangseinheit = 1 Port. Sender und Empfänger links/ rechts aufgeteilt.
Da du noch keinen Datastore aktiv hast, kannst du gefahrlos ja immer noch alles ändern. Halte zu erst die 2 Stecker nebeneinander. Schau dir die gelben Marker an.
NAS: Port 0 A / B - links / rechts
ESXi: Port 0 B / A - links / rechts
Wenn die Anordnung schon gekreuzt ist, musst du die Richtungen nicht umkehren. Die Farben lassen es vermuten. Schau dir aber lieber die gelben Marker-Blöcke an! Dan bist du normal auf der sicheren Seite. Sollten die ernsthaft falsch sein - was kaum vorkommt - so könntest du bei kurzer Strecke auch das Kabel lang hinlegen und prüfen ob sich die Fasern Kreuzen. A -> B und B -> A.
Da einige kurze Kabel so zum rangieren vorgesehen sind, mag es am Werk schon so sein. Prüfen sollte man es in deinen Fall aber.
Ansonsten musst du die Biegeradien einhalten. Wenn man unachtsam war, kann es sein das Kabel beschädigt ist und kein Licht mehr durch kommt. Es ist kein Spielzeug! Zum Prüfen einfach gegen ein Blatt Papier halten. Normal sollte man dann die Lichtblitze sehen. Das bedeutet aber auch nur, dass überhaupt die Strahlen durchgeleitet werden. Mehr erstmal noch nicht.
Du hast ja wegen den Switch mehrere Kabel richtig? Also kannst du es ja auch austauschen, um zu prüfen ob das eine ggf. beschädigt ist.
ROT rechts / links.
Farben sind aber auch so eine Sache. Der Marker mit A/B weiter unte in gelb sollte ggf. mal geprüft werden.
@dbox3 Eine Sende-/ Empfangseinheit = 1 Port. Sender und Empfänger links/ rechts aufgeteilt.
Da du noch keinen Datastore aktiv hast, kannst du gefahrlos ja immer noch alles ändern. Halte zu erst die 2 Stecker nebeneinander. Schau dir die gelben Marker an.
NAS: Port 0 A / B - links / rechts
ESXi: Port 0 B / A - links / rechts
Wenn die Anordnung schon gekreuzt ist, musst du die Richtungen nicht umkehren. Die Farben lassen es vermuten. Schau dir aber lieber die gelben Marker-Blöcke an! Dan bist du normal auf der sicheren Seite. Sollten die ernsthaft falsch sein - was kaum vorkommt - so könntest du bei kurzer Strecke auch das Kabel lang hinlegen und prüfen ob sich die Fasern Kreuzen. A -> B und B -> A.
Da einige kurze Kabel so zum rangieren vorgesehen sind, mag es am Werk schon so sein. Prüfen sollte man es in deinen Fall aber.
Ansonsten musst du die Biegeradien einhalten. Wenn man unachtsam war, kann es sein das Kabel beschädigt ist und kein Licht mehr durch kommt. Es ist kein Spielzeug! Zum Prüfen einfach gegen ein Blatt Papier halten. Normal sollte man dann die Lichtblitze sehen. Das bedeutet aber auch nur, dass überhaupt die Strahlen durchgeleitet werden. Mehr erstmal noch nicht.
Du hast ja wegen den Switch mehrere Kabel richtig? Also kannst du es ja auch austauschen, um zu prüfen ob das eine ggf. beschädigt ist.
https://kb.vmware.com/s/article/1016836
Neben der Verkabelung gibt es da noch ein paar Dinge zu prüfen.
Ggf. mal alles weg löschen und mit der Konfiguration von NAS und ESXi neu beginnen.
Edit: ist iSCSI beschrieben. Daruma auch unten der Hinweis mit der doppelten IP.
https://www.youtube.com/watch?v=E5Cng2G-W9s
Ggf. hilft dir das weiter.
Neben der Verkabelung gibt es da noch ein paar Dinge zu prüfen.
Ggf. mal alles weg löschen und mit der Konfiguration von NAS und ESXi neu beginnen.
Edit: ist iSCSI beschrieben. Daruma auch unten der Hinweis mit der doppelten IP.
https://www.youtube.com/watch?v=E5Cng2G-W9s
Ggf. hilft dir das weiter.
wobei es auf dem Bild oben richtig aussieht.
Mmmhhh.. Sieht eher nach einem 1:1 Kabel ohne Drehung aus was nicht funktionieren würde. Man kann eben leider den Marker nicht richtig sehen um das sicher sagen zu können. Zitat von @aqui:
wobei es auf dem Bild oben richtig aussieht.
Mmmhhh.. Sieht eher nach einem 1:1 Kabel ohne Drehung aus was nicht funktionieren würde. Man kann eben leider den Marker nicht richtig sehen um das sicher sagen zu können. Ich denke nicht, dass der TO exakt dieses Kabel nutzt (aber vielleicht doch
)Das Bild selbst ist aber schon eindeutig: rot ist die "1", schwarz die "2".
Halte ich die Stecker gedanklich beide hochkant (Klipp/Nase zu mir zeigend, LWL-Kontakt nach oben gerichtet), ist rot einmal links und einmal rechts.
Also es muss nicht zwingend ein Problem mit der Verkabelung sein. es kann auch ein Softwareproblem sein, denke ich. Aber das mit dem Kabel bekommt man am schnellsten gesichtet.
@aqui ich kaue gerade auf was anderen rum.
Der Switch. Glasfaser ist ja nur ein Medium. Man kann auch IPs drüber jagen. In den Youtube Video ist ja iSCSI vs. FC und die Layers gegenübergestellt. Ist ja kein SAN Switch den er da hat.
Neben der richtigen Polarität würde ich klein anfangen. Zum Managen für Host und NAS reicht ja erstmal 1x Ethernet - auch wenn der ESXi da immer meckert.
Dann NUR 1-Strecke aufbauen mit FC: NAS <-> ESXi Host.
Wir sehen ja im Log ein Device: naa.xxxxxxxxx - das kommt ja nicht aus der Luft.
https://kb.vmware.com/s/article/1014953
Ich verstehe noch nicht komplett den Aufbau! 1x GBIC für Storage 1:1 Anbidung. 1x GIBC für normal TCP/ IP Netzwerk? Oder kann der Switch da mehr.
Würde alles löschen. 1:1 GBIC NAS <-< ESXi Host und dann erstmal Storge nur anbinden. Alles andere auf "default" lassen und 1x Ethernet Port die 2x Geräte einrichten.
SFP+ gibt es ja auch. 10 GBit/ 1Gbit etc. Wenn die Module aber inkompatibel sind, sollten es doch auch hier keine naa-ID geben?
Ich würde drum bitten die Diagnostik aus den Beitrag oben zu betreiben. Was der ESXi host trotz TRENNUNG zuvor gesehen hat. Bzw. ob da noch Daten zum Device zu finden sind!
Da ist auch nochmal erklärt, wie man die Geräte abfragt und an die Daten kommt. Hätte bei einen Dreher erwartet, dass keine naa auftaucht. Auch wenn aktuell es GETRENNT ist, liefern ggf. die Befehle aus den Beitrag mehr Infos. Wenn dort das NAS auftaucht, müsste die Richtung eig stimme. Woher soll der Host sonst die Infos haben, wenn Sender auf Sender prallt?
Der Switch. Glasfaser ist ja nur ein Medium. Man kann auch IPs drüber jagen. In den Youtube Video ist ja iSCSI vs. FC und die Layers gegenübergestellt. Ist ja kein SAN Switch den er da hat.
Neben der richtigen Polarität würde ich klein anfangen. Zum Managen für Host und NAS reicht ja erstmal 1x Ethernet - auch wenn der ESXi da immer meckert.
Dann NUR 1-Strecke aufbauen mit FC: NAS <-> ESXi Host.
Wir sehen ja im Log ein Device: naa.xxxxxxxxx - das kommt ja nicht aus der Luft.
https://kb.vmware.com/s/article/1014953
Ich verstehe noch nicht komplett den Aufbau! 1x GBIC für Storage 1:1 Anbidung. 1x GIBC für normal TCP/ IP Netzwerk? Oder kann der Switch da mehr.
Würde alles löschen. 1:1 GBIC NAS <-< ESXi Host und dann erstmal Storge nur anbinden. Alles andere auf "default" lassen und 1x Ethernet Port die 2x Geräte einrichten.
SFP+ gibt es ja auch. 10 GBit/ 1Gbit etc. Wenn die Module aber inkompatibel sind, sollten es doch auch hier keine naa-ID geben?
Ich würde drum bitten die Diagnostik aus den Beitrag oben zu betreiben. Was der ESXi host trotz TRENNUNG zuvor gesehen hat. Bzw. ob da noch Daten zum Device zu finden sind!
Da ist auch nochmal erklärt, wie man die Geräte abfragt und an die Daten kommt. Hätte bei einen Dreher erwartet, dass keine naa auftaucht. Auch wenn aktuell es GETRENNT ist, liefern ggf. die Befehle aus den Beitrag mehr Infos. Wenn dort das NAS auftaucht, müsste die Richtung eig stimme. Woher soll der Host sonst die Infos haben, wenn Sender auf Sender prallt?
Das Bild selbst ist aber schon eindeutig: rot ist die "1", schwarz die "2".
Wichtig ist dann aber die andere Seite. Wenn da auch rot "1" und schwarz "2" ist scheitert die Verbindung. RX auf RX und TX auf TX klappt bekanntlich nicht. Weder bei Eternit noch Fiberchannel. 
@Crusher79
Ich hoffe ja nicht, dass er da nen Switch zwischen hat!
Normale Ethernet Switche funktionieren nicht mit FC!
Wenn, dann brauch es entweder explizite SAN-Switche (nicht günstig) oder es gibt glaube ich auch Switche, die Ethernet UND FC können (meine mich jedenfalls erinnern zu können)
Wenn ich mir das gerade hier mal so richtig noch mal Revue passieren lasse:
Der TO hat in der QNAP nur eine 2Port Karte. Folglich kann jeder ESXi dann auch nur mit einem FC-Port angeschlossen werden, wenn es 1:1 wird!
@to: hast du da einen Switch zwischen gesetzt?
Ich hoffe ja nicht, dass er da nen Switch zwischen hat!
Normale Ethernet Switche funktionieren nicht mit FC!
Wenn, dann brauch es entweder explizite SAN-Switche (nicht günstig) oder es gibt glaube ich auch Switche, die Ethernet UND FC können (meine mich jedenfalls erinnern zu können)
Wenn ich mir das gerade hier mal so richtig noch mal Revue passieren lasse:
Der TO hat in der QNAP nur eine 2Port Karte. Folglich kann jeder ESXi dann auch nur mit einem FC-Port angeschlossen werden, wenn es 1:1 wird!
@to: hast du da einen Switch zwischen gesetzt?
Die Karten von den ESXi's sind mit jeweils einem Port an den QNAP angeschlossen und mit dem Anderen an einen Juniper EX2200-Switch.
Jup hatte es falsch im Hinterkopf. Der ESXi ist mit dem Switch via FC dann wohl auch noch vrebunden?!?
Wir haben ja NFS, iSCSI, FC. Sind wir mit dem Adapter aus dem Kernel Log bei FC oder ist das via Ethernet und iSCSI, da dass NAS ja ALLES kann.
Ich würde um Verwirrugen zu vermeiden ggf. da nochmal von vorne anfangen. Die naa-ID heisst ja normal, dass etwas gefunden wurde. Das dürfte ja bei fehlender Kommunikation nicht sein. Quasi kurz verbunden dann getrennt ?!?
Damit wir uns nicht im FC-Dschungel verlieren würde ich vorschlagen nur mit Ethernet zu managen. FC für Datastore hernehmen und dann weiterschauen.
esxcli storage core path list or esxcfg-scsidevs -l Zwar JETZT GETRENNT, aber Verbindung war schon kurz da?!? Was listet der Befehl aktuell? Ist da das QNAP zu sehen?
Das ist aber einiges an Infos, die ich erstmal verdauen muss. Die physische Verschlatung checke ich dann erst morgen vor Ort. Wenn ich das jetzt richtig verstannden habe, muss z.B. A-Faser beim NAS li. und beim ESXi re. und die B-Faser umgekehrt. Rigtig? OK. naa.XXXXXXX im Log ist vermutlich die iSCSI-Verbindung zum NAS über NIC/iSCSI-Adapter.
Ja genau. Die müssen sich kreuzen. Wenn die GBIC Module gleich aufgebaut sind, sind Sender und Empfänger an gleicher Stelle. Das kann dann nur das Kabel "ausgleichen". Früher nutzte ma häufig auch Cross-Over Ethernet Kabel für Direktverbindung von Ethernet zu Ethernet. An der Grundidee hat sich nichts geändert.
NFS, iSCSI, FC - schau dir die Unterschiede an. Für eine 1:1 Verbindung setzt man keine IPs. In den Youtube Video ist es gengenübergestellt.
Um die verschiedenen Formen der Anbindung nicht wild zu vermischen war nur mein Ratschlag tiefer zu stapeln. Ganz schnöde mit 2x Netzwerkkabeln und den Switch Host und NAS einzurichten. Dann im nächsten Schritt die GBIC mit FC verbinden und einrichten.
Du siehst ja in den VMware Beitrag dass die Befehle dann die Storage Devices auflisten. Da steht dann auch was von "FC" und IDs.
Diese Daten kommen nicht aus der Luft! Wenn hier das NAS via FC-Strecke aufgelistet wird, dann sind die Fasern A/B richtig gekreuzt. Wenn die falsch wären findet Null-Kommunikation statt und man würde hier nichts brauchbares finden.
Die Frage ist dann wiederum, warum die Verbindung getrennt wird. Mein Post oben ist etwas irreführend! VMware geht hier auf iSCSI ein. Du hast ja die Devices direkt verbunden. Doppelte IP u.ä. kommt hier nicht vor!
Schau dir kurz mal die Unterschiede der Techniken an: NFS, iSCSI, FC direkt. Ebenso Ethernet Swicht vs. SAN-Switch. Wozu man was braucht. GBIC passen ins viles. Glasfaser ist nur ein dummes Medium!!!! Der Spass fängt erst dann an.
@em-pie hat ja schon auf Software-Fehler hingewiesen! Wenn irgendwo das NAS FC "mäßig" auftaucht dann ist die Verkabelung richtig. Die Frage ist, warum die Verbindung flöten geht! Kabel defekt? Fehlerhafte Konfiguration?
LUN beginnen bei 0. ESXi mag nicht wenn es mit 1, 2 oder 3 losgeht. Mitunter kann man sowas nicht beeinflussen, da der Reihenfolge nach die Speicher selber die Folge vergeben.
ESXi setzt immer kompatibele Hardware voraus! Sonst wird es ekelhaft. Bzw. funktioniert nicht alles so, wie erwartet. Das kommt leider immer noch hinzu! Gerade auch da ab 7.x legacy Treiber rausgeworfen wurden.
Ansonsten überlässt man das denken hier den Pferden! NAS gibt Speicher vor und die HBA Karte stellt es zur Verfügung. Da ist nicht viel dann zu konfigurieren im Normalfall!
Es gibt auch Karten die RAID Modus können und die LUNs beim Booten anzeigen. Ist aber alles Unsinn, bzw. durch die Brust ins Auge! Mit einer HBA Karte für 1:1 Verbindung ist im Prinzip schon mal die richtige Richtung vorgegeben!
Nun ist die Frage ob das NAS via FC gesehen wird! Wenn JA, dann stimmen die Kabel Verbindungen! Heisst aber auch, es liegt an was anderen, dass das Ding GETRENNT ist. Es heisst ja auch GETRENNT und nicht: Wurde NIE, gar nie nicht gefunden!
NFS, iSCSI, FC - schau dir die Unterschiede an. Für eine 1:1 Verbindung setzt man keine IPs. In den Youtube Video ist es gengenübergestellt.
Um die verschiedenen Formen der Anbindung nicht wild zu vermischen war nur mein Ratschlag tiefer zu stapeln. Ganz schnöde mit 2x Netzwerkkabeln und den Switch Host und NAS einzurichten. Dann im nächsten Schritt die GBIC mit FC verbinden und einrichten.
Du siehst ja in den VMware Beitrag dass die Befehle dann die Storage Devices auflisten. Da steht dann auch was von "FC" und IDs.
Diese Daten kommen nicht aus der Luft! Wenn hier das NAS via FC-Strecke aufgelistet wird, dann sind die Fasern A/B richtig gekreuzt. Wenn die falsch wären findet Null-Kommunikation statt und man würde hier nichts brauchbares finden.
Die Frage ist dann wiederum, warum die Verbindung getrennt wird. Mein Post oben ist etwas irreführend! VMware geht hier auf iSCSI ein. Du hast ja die Devices direkt verbunden. Doppelte IP u.ä. kommt hier nicht vor!
Schau dir kurz mal die Unterschiede der Techniken an: NFS, iSCSI, FC direkt. Ebenso Ethernet Swicht vs. SAN-Switch. Wozu man was braucht. GBIC passen ins viles. Glasfaser ist nur ein dummes Medium!!!! Der Spass fängt erst dann an.
@em-pie hat ja schon auf Software-Fehler hingewiesen! Wenn irgendwo das NAS FC "mäßig" auftaucht dann ist die Verkabelung richtig. Die Frage ist, warum die Verbindung flöten geht! Kabel defekt? Fehlerhafte Konfiguration?
LUN beginnen bei 0. ESXi mag nicht wenn es mit 1, 2 oder 3 losgeht. Mitunter kann man sowas nicht beeinflussen, da der Reihenfolge nach die Speicher selber die Folge vergeben.
ESXi setzt immer kompatibele Hardware voraus! Sonst wird es ekelhaft. Bzw. funktioniert nicht alles so, wie erwartet. Das kommt leider immer noch hinzu! Gerade auch da ab 7.x legacy Treiber rausgeworfen wurden.
Ansonsten überlässt man das denken hier den Pferden! NAS gibt Speicher vor und die HBA Karte stellt es zur Verfügung. Da ist nicht viel dann zu konfigurieren im Normalfall!
Es gibt auch Karten die RAID Modus können und die LUNs beim Booten anzeigen. Ist aber alles Unsinn, bzw. durch die Brust ins Auge! Mit einer HBA Karte für 1:1 Verbindung ist im Prinzip schon mal die richtige Richtung vorgegeben!
Nun ist die Frage ob das NAS via FC gesehen wird! Wenn JA, dann stimmen die Kabel Verbindungen! Heisst aber auch, es liegt an was anderen, dass das Ding GETRENNT ist. Es heisst ja auch GETRENNT und nicht: Wurde NIE, gar nie nicht gefunden!
Habe jetzt alle Kabel geprüft. Die Verschlatung ist OK. Das Problem wird der NAS sein, denn am Ausgang ist kein Leuchten zu erkennen. Morgen muss ich wohl QNAP kontaktieren. An der Karte selbst leuchten jeweils alle 3 LED's durchgehend während sie an den ESXi's blinken.
Vielen Dank für die Hilfe. Melde mich wieder, sobald QNAP reagiert.
Vielen Dank für die Hilfe. Melde mich wieder, sobald QNAP reagiert.
Wenn das Problem bei der QNAP liegt, dann prüfe, wie Verbindung ESXi mit NAS über Fibre Channel hier geschrieben, ob die Karte wirklich supported wird. Im WWW gibt es einige, die ein Problem mit gabrandeten Karten (HP, Lenovo, …) haben…
Das wird es sein. Im QNAP werden und Netzwerk- Glasfaserkanal zwei Adapter HPAJ764A angezeigt. Es ist vermutlich HP-Branding. Dann wird es mit diesem Adapter bei QNAP wohl nichts.
Im QNAP werden und Netzwerk- Glasfaserkanal zwei Adapter HPAJ764A angezeigt.
Der Satz ist etwas kryptisch und nicht verständlich da auch der Begriff "Netzwerk" und "Glasfaser" hier leider doppeldeutig ist.Fakt ist das beide QNAP Ports reine FibreChannel Ports sind! Also kein Ethernet! Fibrechannel ist eine reine Storage Technik.
Sie können also dann folglich rein nur mit Fibrechannel und der/den entsprechenden HBAs im ESXi verbunden werden. Ethernet ist hier komplett raus! Fibrechannel und Ethernet sind bekanntlich NICHT kompatibel obwohl es auch hybride Switches gibt wie Kollege @em-pie richtig sagt. Dort wird aber Ethernet nur als FC Transportmedium benutzt (FCoE). Ist hier aber kein Thema!
Die Frage ob du die Fibrechannel Verbindung HBA und QNAP direkt machst oder ob da ggf. noch ein Fibrechannel Switch dazwischen ist hattest du noch nicht beantwortet!
Dann wird es mit diesem Adapter bei QNAP wohl nichts.
Erkannt wird er aber! Fibrechannel selber ist ein Standard. HP HBAs arbeiten über z.B. Brocade FC Switches auch mit IBM Servern usw. QNAP wird ja vermutlich kaum Adapter in seinen NAS Storage Produkten verbauen die Nutzer auf eine HP Hardware zwingt wenn die IBM oder Supermicro oder was auch immer als Server im Einsatz haben. Damit wären sie ja unverkäuflich.
Bei großen Speichern wie FS Eternus kann man die Host Response einstellen.
Wir hätten in deinen Fall nur eine 1:1 Verbindung. Falsche Einstellungen bei der Host Response können dazu führen das Speicher zwar kurrzeitig gesehen wird, aber nicht genutzt werden kann.
Ich kennen QNAP leider nicht. Darum sagte ich oben schon: ggf. hier alles rauslöschen und von vorne beginnnen.
In meinen Fall damals war der Speicher wegen falsche Host Response zwar "irgendwie" sichtbar, aber nicht nutzbar. Tauchte irgendwie auf. Nach der Korrektur lief es dann als Local FUJITSU Disk (naa.600000e00d2800000028318400000000)
Aber JA, davor war es auch sichbar. Die Bezeichung war nur leicht anders.
Warum der Exkurs? Wie @aqui schon sagte muss die Karte nicht inkompatibel sein!
Wie der Speicher angebunden wird ist in Templates teils vorgegeben. Kann es mit Hersteller und Modell keine Eintrag finden, wird die Anbindung auf andere Art vollzogen. Eternus war bei mir zwar drin, aber NICIHT mein Modell.
Du siehst "irgendwas". Ich gehe davon aus dass die "Polarität" richtig ist. Mir brach damals der TPGS Mode das Genick. Device warzwar drin, aber falsch angebunden und damit inaccessible.
Wir nutzen im Moment für Spezial-Projekt nur 1 Lun. Ganz sauber war es mit der HP SmartArray FC RAID Karte nicht. die musste man auf HBA umstellen. Ist aber bei dir NICHT der Fall.
Wenn wir nun folgendes unterstellen:
- 1:1 Verbindung
- Speicher "irgendwie" kurz sichtbar
Dann wäre nun der nächste Step zu schauen ob QNAP die Host Response dich da weiter einstellen lässt. Ob du da irgendwo falsch abgebogen bist.
Wir hätten in deinen Fall nur eine 1:1 Verbindung. Falsche Einstellungen bei der Host Response können dazu führen das Speicher zwar kurrzeitig gesehen wird, aber nicht genutzt werden kann.
Ich kennen QNAP leider nicht. Darum sagte ich oben schon: ggf. hier alles rauslöschen und von vorne beginnnen.
In meinen Fall damals war der Speicher wegen falsche Host Response zwar "irgendwie" sichtbar, aber nicht nutzbar. Tauchte irgendwie auf. Nach der Korrektur lief es dann als Local FUJITSU Disk (naa.600000e00d2800000028318400000000)
Aber JA, davor war es auch sichbar. Die Bezeichung war nur leicht anders.
Warum der Exkurs? Wie @aqui schon sagte muss die Karte nicht inkompatibel sein!
Wie der Speicher angebunden wird ist in Templates teils vorgegeben. Kann es mit Hersteller und Modell keine Eintrag finden, wird die Anbindung auf andere Art vollzogen. Eternus war bei mir zwar drin, aber NICIHT mein Modell.
Du siehst "irgendwas". Ich gehe davon aus dass die "Polarität" richtig ist. Mir brach damals der TPGS Mode das Genick. Device warzwar drin, aber falsch angebunden und damit inaccessible.
Wir nutzen im Moment für Spezial-Projekt nur 1 Lun. Ganz sauber war es mit der HP SmartArray FC RAID Karte nicht. die musste man auf HBA umstellen. Ist aber bei dir NICHT der Fall.
Wenn wir nun folgendes unterstellen:
- 1:1 Verbindung
- Speicher "irgendwie" kurz sichtbar
Dann wäre nun der nächste Step zu schauen ob QNAP die Host Response dich da weiter einstellen lässt. Ob du da irgendwo falsch abgebogen bist.
https://forum.qnap.com/viewtopic.php?t=165622
iSCSI = FC ???
Ggf. schau mal bei QNAP im Forum. Die haben scheinbar eine eigene Auffassung.
Wie @aqui schon sagte sind es 2 Standards! Die Frage ist wie QNAP damit umgeht. Ggf. wäre dieses Topic bei denen besser aufgehoben.
Rein techn. kann man dir bei uns leicht folgen. Aber so die Spezialitäten sind ggf. da besser aufgehoben. NAS haben viele. Aber viele nutzen NFS !
Ich rate dazu dein Vorhaben dort anzudiskutieren. @em-pie hat dich ja oben auch schon auf die "Software" hingeweisen!
Falsche Host Response macht komische Sachen. Erst recht wenn man die Response nicht einstellen kann ?!?
Rate zu direkten Austausch bei QNAP.
iSCSI = FC ???
Ggf. schau mal bei QNAP im Forum. Die haben scheinbar eine eigene Auffassung.
Wie @aqui schon sagte sind es 2 Standards! Die Frage ist wie QNAP damit umgeht. Ggf. wäre dieses Topic bei denen besser aufgehoben.
Rein techn. kann man dir bei uns leicht folgen. Aber so die Spezialitäten sind ggf. da besser aufgehoben. NAS haben viele. Aber viele nutzen NFS !
Ich rate dazu dein Vorhaben dort anzudiskutieren. @em-pie hat dich ja oben auch schon auf die "Software" hingeweisen!
Falsche Host Response macht komische Sachen. Erst recht wenn man die Response nicht einstellen kann ?!?
Rate zu direkten Austausch bei QNAP.
1
Die HBA ist in der Kompatibilitätsliste von HP grundsätzlich vorhanden. Ist es vielleicht möglich, das Branding von HP irgenwie durch einen Patch oder FW-Upgrade zu entfernen und so die Chance für die Kompatibilität mit QNAP zu erhöhen?
Laut deinem QNAP Screenshot ist dort doch ein 2 Port, 8 Gig Qlogic HPAJ764A verbaut. Per se also mit HP Kompatibilität. Deshalb verwirrt deine Frage etwas... 🤔
Und nochmals: Fibrechannel ist ein weltweiter Standard wie Ethernet. Dort arbeitet jeder mit jedem zusammen. Es wäre doch ökonomisch völlig sinnfrei, wie oben schon gesagt, wenn QNAP mit seinem Adaptern im NAS Nutzer dazu zwingt eine ganz bestimmte Herstellerplattform auf der Serverseite zu verwenden und vice versa. Sowas macht doch kein Storage Hersteller sich ins eigene Knie zu schiessen!
Und nochmals: Fibrechannel ist ein weltweiter Standard wie Ethernet. Dort arbeitet jeder mit jedem zusammen. Es wäre doch ökonomisch völlig sinnfrei, wie oben schon gesagt, wenn QNAP mit seinem Adaptern im NAS Nutzer dazu zwingt eine ganz bestimmte Herstellerplattform auf der Serverseite zu verwenden und vice versa. Sowas macht doch kein Storage Hersteller sich ins eigene Knie zu schiessen!
Logisch ist es. In der Liste der erkannten Hardware an anderer Stelle ist die verbaute HBA nicht vorhanden. Mit der Handykamera sehe ich auch keine Leuchten an der Schnittstelle. Also ist die Karte nach meinem Verständnis doch nicht einsatzbereit.
Sehr interessant...
Hier wird dein Problem qausi auch beschrieben:
https://forum.qnap.com/viewtopic.php?t=152376
Was mich aber wundert, ist, dass dein QNAP die Karte doch irgendwie erkennt:
ich hätte ja fast gesagt, nimm ne FC-Karte direkt von QNAP, aber die "kleine", mit 2x16G kostet ja auch ein halbes Vermögen...
Hier wird dein Problem qausi auch beschrieben:
https://forum.qnap.com/viewtopic.php?t=152376
Was mich aber wundert, ist, dass dein QNAP die Karte doch irgendwie erkennt:
Zitat von @dbox3:
Das wird es sein. Im QNAP werden und Netzwerk- Glasfaserkanal zwei Adapter HPAJ764A angezeigt. Es ist vermutlich HP-Branding. Dann wird es mit diesem Adapter bei QNAP wohl nichts.
Das wird es sein. Im QNAP werden und Netzwerk- Glasfaserkanal zwei Adapter HPAJ764A angezeigt. Es ist vermutlich HP-Branding. Dann wird es mit diesem Adapter bei QNAP wohl nichts.
ich hätte ja fast gesagt, nimm ne FC-Karte direkt von QNAP, aber die "kleine", mit 2x16G kostet ja auch ein halbes Vermögen...
1
Was auch möglich ist das die FC Optiken (sofern die Karte SFP Ports hat?!) keine HP gebrandeten sind. Hier greift dann wieder das Gespenst der Kompatibilität denn HP Karten werden nur HP gebrandete SFP Optiken supporten.
Nach Support-Anfrage bei QNAP heisst es, mein Modell unterstützt die HBA nicht. In der Liste ist das Modell TS-673A aufgeführt und ich habe das TS-673. Also bleibt mir wohl nur die teure Original-HBA von QNAP oder das Ganze vergessen.
FC ist ein Weg. Das Vierh hat ja 4x Ethernet.
Was wäre klassich mit NFS? Es git ja versch. Platten: SATA, SAS, NL-SAS. Switch mit LAG würde schon 4 GBit th. an Anbindung bedeuten.
Das ganze ist doch eh mehr Homelab oder was hast du vor?
Was wäre klassich mit NFS? Es git ja versch. Platten: SATA, SAS, NL-SAS. Switch mit LAG würde schon 4 GBit th. an Anbindung bedeuten.
Das ganze ist doch eh mehr Homelab oder was hast du vor?
Die ursrüngliche Idee war, ein gemeinsamen Speicher auf dem NAS für zwei ESXi einzurichten, um HA zu aktivieren. Die Anwendung (eine DB-Software basierend auf Oracle) hackte aber im Test selbst mit aktiviertem SSD-Provisioning auf dem QNAP dabei. Meine Hoffnung war, die Performance durch FC zu verbessern, da die Ressourcen auf dem NAP (Prozessor bsw. Netzlast) durch FC geschont werden und die Bandbreite deutlich größer ist. Ein gemeinsamer Speicher ginge theoretisch auch mit vSAN von VMware, bei nur 2 ESXi kriege ich es irgendwie nicht eingerichtet. Standardmäßig sind mindestens 3 nötig. Vielleicht ist das Ganze ein falscher Ansatz. Jeder Verbesserungsvorschlag ist jedoch willkommen.
Ist das ein Produktiv-Sytem?
Was sind das für Server?
Warum kein Systemhaus mit der Konzeption des Gesamt-System beauftragt?
Mein 3 Knoten esx-Host ist per direkt FC an ein (richtiges) SAN angebunden. 2x 16GB FC pro Server. Alles von Dell. Über die Performance kann ich nicht klagen.
Es läuft unser ERP-System mit M$-SQL-DB.
Jürgen
Was sind das für Server?
Warum kein Systemhaus mit der Konzeption des Gesamt-System beauftragt?
Mein 3 Knoten esx-Host ist per direkt FC an ein (richtiges) SAN angebunden. 2x 16GB FC pro Server. Alles von Dell. Über die Performance kann ich nicht klagen.
Es läuft unser ERP-System mit M$-SQL-DB.
Jürgen
