Neue VMware/Nexus/ Datacore Umgebung->SCSI Bus Reset

[nikzin]

Hallo zusammen,
wir bauen zurzeit einen neue VMware Umgebung auf. Sie besteht aus einigen ESXi 5.1 Hosts, basiernd auf Dell R820. Als Storage Adapter kommen CNAs von Qlogic QLE 8262 zum Einsatz. Obwohl es CNAs sind und wir theoretisch LAN und SAN über diese Karten abfackeln könnten, tun wir dies nicht. Die zwei CNA Storage Ports gehen an jeweils einen Cisco Nexus 5548UP. Zwischen ESXi und Nexus (NX-OS 5.2) wird FCoE gesprochen. Als Storage kommt eine gespiegelte Datacore 9.0 PSP3 Update 1 Umgebung zum tragen basierend auf Dell R720+ MD1220 Storage, der über external SAS an der R720 Server angeschlossen ist. In den Datacore Server sind FC HBAs QLE 2562 eingebaut. Pro Datacore Server gehen zwei Ports (+ 2 x Mirrorports , aber die interessieren jetzt nicht) an die Nexus Switches. Zwischen jedem ESX Host und den beiden Datacore Server bestehen vier Zonings. Die gesamte Umgebung basiert auf einem Single Initiator/ Single Target Zoning.

So, jetzt zu meinem Problem: Wenn ich einen ESX reboote (egal welchen) erhalte ich während dem Neustart (bevor ESXi geladen wird) eine Meldung via Mail von dem Datacoresystem:

02.08.2013 11:30:51 - Log messages matching [Log level = Warning] Or [Log level = Error] posted
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx06-s3p2 on bvmesx06.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx02-s3p2 on bvmesx02.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx22-s6p1 on bvmesx22.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx01-s3p2 on bvmesx01.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx41-s3p2 on bvmesx41.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx05-s3p2 on bvmesx05.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx43-s3p2 on bvmesx43.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx52-s3p2 on bvmesx52.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx42-s3p2 on bvmesx42.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx51-s3p2 on bvmesx51.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx21-s6p1 on bvmesx21.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx53-s3p2 on bvmesx53.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx08-s3p2 on bvmesx08.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx07-s3p2 on bvmesx07.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx03-s3p2 on bvmesx03.
Warning: Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx04-s3p2 on bvmesx04.

Auch auf den ESX Hosts und den Nexus Switches ist der SCSI Bus Reset nachzuvollziehen. Inzwischen haben wir alle Hersteller von Vmware, Cisco,Dell, Datacore mit im Boot und checken, warum dieser Bus Reset durchgeführt wird. Bisher wurde folgende Maßnahmen ergriffen, um das Problem zu beheben:

* Update der Firmware und Treiber aller Dell HW Komponenten in der gespiegelten Datacore Umgebung mit der aktuellen Dell SUU 7.3 DVD
* Update der gespiegelten Datacore Umgebung auf 9.0 PSP 3, Update 1
* Eindeutige FC ID Konfiguration aller Datacore Ports (Mirror und Application) auf beiden Nexus SAN Switches
* Update eines ESX Host von ESXi 5.1.0 1065491 auf 5.1.0 1157734
* Qlogic Fast!UTIL: "Selectable Boot Settings" - "disabled" (Erfolglos, anschließend wieder auf "enabled" gesetzt)
* Qlogic Fast!UTIL: "Advanced Adpater Settings" - "Enable Target Reset" "No" (Erfolglos, anschließend wieder auf "Yes" gesetzt)
* Update der CNA Firmware von 01.11.29 auf 01.12.61
* FC Kabel (Application) an Datacoresystemen gezogen und ESX rebootet, um zu überprüfen, ob der Bus Reset "mitwandert" (Bisher erschien die Meldung immer nur auf dcs01-s2p2-app)

Diese Fehlermeldung hat, außer das sie erzeugt wird, keinen Einfluss auf die VMs, den Zugriff auf LUNs, etc. Aktuell laufen aber auch nur ca. 25 Test/Entwicklungs VMs auf der neuen Umgebung. Bevor dieses Problem nicht gelöst ist, streuben wir uns davor die restlichen 220 VMs zu migirieren, weil wir nicht wissen, wie die Umgebung reagiert, wenn erstmal Last auf ihr ist.

Ich weiß, dass ihr ohne Logs usw. keine defintiven Lösungen nennen könnt, aber vielleich hat ja jmd. noch einen guten Tipp, hat das Problem selbst schonmal gehabt oder hat die Lösung doch sofort parat

Ich hoffe, ich habe alles soweit verständlich erklärt, wenn nicht, einfach fragen.

Ich lese hier viele Threads mit und weiß, dass hier sehr fitte IT-Leute unterwegs sind.

Also, jetzt schonmal Danke.

Viele Grüße,
Nick

[bla!zilla]

Woher weißt du das mit dem Bus reset? Ich sehe da nur den Port Logout. Und das habe ich eigentlich immer, wenn ich einen Host neustarte. Oder muss ich das so lesen, dass beim Neustart EINES ESXi ALLE Kisten einen Port Logout machen?

@ Marcel

Any comments?

[nikzin]

Der Bus Reset ist auf den ESX in den Logs festzustellen. Und ja, du musst es so lesen: Ich boote einen ESX und alle anderen machen ebenfalls einen Port Logout.

[bla!zilla]

Gut, das ist NICHT normal. Ich tippe irgendwie auf die Fabric.

[coyote]

Schon mal andere path policy auf den esx hosts eingestellt? Alua-Volumes oder?
Passier das auch bei non-mirror Volumes?

[nikzin]

Also normalerweise haben wir Round Robin und als Storage Array Type "VMW_SATP_ALUA".

Jetzt habe ich an einem ESX alle Volumes auf Fixed umgestellt und einen anderen ESX rebootet. Das Problem tritt weiterhin an allen ESX auf.

Non-Mirror Volumes haben wir nicht im Einsatz.

Ich persönlich denke, dass die CNAs das Problem sind. Wir haben nämlich einen unserer älteren ESX Host, der noch FC HBAs verbaut hat, an die neue Umgebung angeschlossen, entsprechend gezont und anschließend rebootet. Wenn ich diesen ESX boote tritt das Problem nicht auf.

Bei Dell haben wir inzwischen auch ein Ticket auf. Die reden zurzeit mit Qlogic, allerdings warte ich hier noch auf Feedback.

Die Fabric hatte ich anfangs auch in Verdacht, weil wir nicht eindeutige FC IDs an den Ports hatten, an denen die Datacoresysteme hängen. Das haben wir aber inzwischen bereinigt und der Port Logout ist weiterhin auf allen Hosts vorhanden.

Bin dankbar für jeden Denkanstoss...

[coyote]

Teste mal Iscsi/fcoe wenn frontend Ethernet auf den datacores vorhanden ist mit den cna's.
Laut tb's von datacore muss die path policy und lun-id auf allen hosts identisch sein, die gleiche schared Volumes hosten.

[kastlr]

Hallo,

ich würde zuerst versuchen, die Anzahl der möglichen Fehlerquellen zu minimieren.
So ist mir anhand eurer Erklärungen nicht klar, wann genau der SCSI Busreset erfolgt.

Um dies weiter einzugrenzen, könntet Ihr z.B. folgende Tests durchführen,

• den Host im BIOS abfangen
• den Host im CNA BIOS abfangen

Tritt der Fehler bereits zu diesem Zeitpunkt auf, ist VMware außen vor, das es noch gar nicht geladen ist.
Ist bis dahin kein Fehler zu erkennen, würde ich mir

• die Parameter des CNA (FC) Treibers
• die Einstellungen der VMware Advanced Settings im Bereich SCSI und Disk

ansehen.

Damit solltet ihr zumindest in der Lage sein, den zu untersuchenden Bereich deutlich einzugrenzen.

Viel Erfolg,
Ralf

[nikzin]

@coyote: iSCSI Konfiguration ist bei uns nicht möglich. Uns stehen für die Datacore Frontend Ports lediglich FC HBAs zur verfügung.
An die Datacore TBs halten wir uns streng. Selbstverständlich ist die LUN ID auf allen Hosts identisch und die Path Policy ist, abgesehen von dem gestrigen Test, wo ich die LUNs an einem Host von Round Robin auf Fixed gestellt, auch identisch.

@kastlr: Der Fehler tritt auf, kurz nachdem die CNA Adapter initialisiert werden. VMware wird zu diesem Zeitpunk noch nicht geladen. Genau deswegen ist auch meine Vermutung, dass das Problem der CNA Adapter ist.

Die Einstellungen der CNA Adapter habe ich mir schon angesehen und im CNA BIOS nach jeder gemachten Einstellung den Host rebootet. Folgendes hatte ich geändert:
*Qlogic Fast!UTIL: "Selectable Boot Settings" - "disabled"
*Qlogic Fast!UTIL: "Advanced Adpater Settings" - "Enable Target Reset" "No"

Geholfen haben die Änderungen nichts.

Der SCSI Reset trat weiterhin auf, deswegen habe ich die Settings wieder auf Default gesetzt. Ein Upgrade der CNA Firmware von 01.11.29 auf 01.12.61 habe ich auch durchgeführt. Ohne Erfolg !!!

[MarcelMertens]

Mit fcoe habe ich noch gar keinen kontakt gehabt.
Hast du schon mal in die Datacore Log Console geschautob du dort mehr siehst?
Liegt im datacore Programverzeichnis. Namen habe ich gerade nicht zur hand.

[nikzin]

@marcelmertens: Meinst du die Datei dcsx.dcsl ? Wie kann ich die öffnen ? Mit Notepad oder Notepad++ geht es nicht.

Wenn ich einen Host (ich boote bvmesx06 ) reboote steht in der Datacore GUI unter Log Messages folgendes:

02.08.2013 19:45:20.467 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx06-s3p2 on bvmesx06.
02.08.2013 19:45:20.467 Client bvmesx06 is currently Connected.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx06-s3p2 on bvmesx06.
02.08.2013 19:45:46.484 Client bvmesx06 is currently Not connected.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx02-s3p2 on bvmesx02.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx22-s6p1 on bvmesx22.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx01-s3p2 on bvmesx01.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port FC Port 1 on bvmesx27.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx41-s3p2 on bvmesx41.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx05-s3p2 on bvmesx05.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx43-s3p2 on bvmesx43.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx52-s3p2 on bvmesx52.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx42-s3p2 on bvmesx42.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx51-s3p2 on bvmesx51.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx21-s6p1 on bvmesx21.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx53-s3p2 on bvmesx53.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx08-s3p2 on bvmesx08.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx07-s3p2 on bvmesx07.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx03-s3p2 on bvmesx03.
02.08.2013 19:45:46.484 Port dcs01-s2p2-app on bvmdcs01 has lost connection to port esx04-s3p2 on bvmesx04.
02.08.2013 19:45:46.641 Port dcs01-s3p2-app on bvmdcs01 is connected to port esx06-s3p2 on bvmesx06.
02.08.2013 19:45:46.641 Client bvmesx06 is currently Connected.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx06-s3p2 on bvmesx06.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx02-s3p2 on bvmesx02.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx22-s6p1 on bvmesx22.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx01-s3p2 on bvmesx01.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port FC Port 1 on bvmesx27.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx41-s3p2 on bvmesx41.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx05-s3p2 on bvmesx05.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx43-s3p2 on bvmesx43.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx52-s3p2 on bvmesx52.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx42-s3p2 on bvmesx42.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx51-s3p2 on bvmesx51.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx21-s6p1 on bvmesx21.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx53-s3p2 on bvmesx53.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx08-s3p2 on bvmesx08.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx07-s3p2 on bvmesx07.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx03-s3p2 on bvmesx03.
02.08.2013 19:45:46.781 Port dcs01-s2p2-app on bvmdcs01 is connected to port esx04-s3p2 on bvmesx04.
02.08.2013 19:45:46.953 Running Send an email to Administrator.
02.08.2013 19:45:49.125 Send an email to Administrator completed successfully.
02.08.2013 19:45:58.579 Port dcs02-s2p2-app on bvmdcs02 is connected to port esx06-s4p2 on bvmesx06.
02.08.2013 19:45:58.626 Port dcs02-s3p2-app on bvmdcs02 is connected to port esx06-s4p2 on bvmesx06.


Im vmkernel.log eines betroffenen ESX Hosts stehen zur gleichen Zeit folgende Einträge:

2013-08-02T17:45:47.069Z cpu56:16440)NMP: nmp_ThrottleLogForDevice:2319: Cmd 0x2a (0x412501218140, 19005) to dev "naa.60030d90f7fec9044abe87ffaf256b9c" on path "vmhba2:C0:T2:L0" Failed: H:0x7 D:0x2 P:0x0 Possible sense data: 0x6 0x29 0x0. Act:EVAL
2013-08-02T17:45:47.069Z cpu56:16440)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237:NMP device "naa.60030d90f7fec9044abe87ffaf256b9c" state in doubt; requested fast path state update...
2013-08-02T17:45:47.069Z cpu56:16440)ScsiDeviceIO: 2331: Cmd(0x412501218140) 0x2a, CmdSN 0x80000095 from world 19005 to dev "naa.60030d90f7fec9044abe87ffaf256b9c" failed H:0x7 D:0x2 P:0x0 Possible sense data: 0x6 0x29 0x0.
2013-08-02T17:45:48.845Z cpu42:16426)NMP: nmp_ThrottleLogForDevice:2319: Cmd 0x2a (0x4124c01d3380, 123733) to dev "naa.60030d905117bb027fcc047993498707" on path "vmhba2:C0:T2:L2" Failed: H:0x7 D:0x2 P:0x0 Possible sense data: 0x6 0x29 0x0. Act:EVAL
2013-08-02T17:45:48.845Z cpu42:16426)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237:NMP device "naa.60030d905117bb027fcc047993498707" state in doubt; requested fast path state update...
2013-08-02T17:45:48.845Z cpu42:16426)ScsiDeviceIO: 2331: Cmd(0x4124c01d3380) 0x2a, CmdSN 0xfffffa801953dbe0 from world 123733 to dev "naa.60030d905117bb027fcc047993498707" failed H:0x7 D:0x2 P:0x0 Possible sense data: 0x6 0x29 0x0.
2013-08-02T17:45:49.746Z cpu14:16398)NMP: nmp_ThrottleLogForDevice:2319: Cmd 0x2a (0x4124401fcec0, 16448) to dev "naa.60030d9089f4f80462b3410e4d19e3e7" on path "vmhba2:C0:T1:L1" Failed: H:0x7 D:0x2 P:0x0 Possible sense data: 0x6 0x29 0x0. Act:EVAL
2013-08-02T17:45:49.746Z cpu14:16398)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237:NMP device "naa.60030d9089f4f80462b3410e4d19e3e7" state in doubt; requested fast path state update...
2013-08-02T17:45:49.746Z cpu14:16398)ScsiDeviceIO: 2331: Cmd(0x4124401fcec0) 0x2a, CmdSN 0x39a84 from world 16448 to dev "naa.60030d9089f4f80462b3410e4d19e3e7" failed H:0x7 D:0x2 P:0x0 Possible sense data: 0x6 0x29 0x0.
2013-08-02T17:45:49.850Z cpu26:16410)NMP: nmp_ThrottleLogForDevice:2319: Cmd 0x2a (0x4124801e5540, 16448) to dev "naa.60030d90868b0a06a808c974f2472339" on path "vmhba2:C0:T2:L23" Failed: H:0x7 D:0x2 P:0x0 Possible sense data: 0x6 0x29 0x0. Act:EVAL
2013-08-02T17:45:49.850Z cpu26:16410)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237:NMP device "naa.60030d90868b0a06a808c974f2472339" state in doubt; requested fast path state update...
2013-08-02T17:45:49.850Z cpu26:16410)ScsiDeviceIO: 2331: Cmd(0x4124801e5540) 0x2a, CmdSN 0x17abc from world 16448 to dev "naa.60030d90868b0a06a808c974f2472339" failed H:0x7 D:0x2 P:0x0 Possible sense data: 0x6 0x29 0x0.
2013-08-02T17:45:49.850Z cpu26:16410)NMP: nmp_ThrottleLogForDevice:2319: Cmd 0x2a (0x412481524d80, 16448) to dev "naa.60030d9088880a062f0e49b6ec181c95" on path "vmhba2:C0:T1:L22" Failed: H:0x7 D:0x2 P:0x0 Possible sense data: 0x6 0x29 0x0. Act:EVAL
2013-08-02T17:45:49.850Z cpu26:16410)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237:NMP device "naa.60030d9088880a062f0e49b6ec181c95" state in doubt; requested fast path state update...
2013-08-02T17:45:49.850Z cpu26:16410)ScsiDeviceIO: 2331: Cmd(0x412481524d80) 0x2a, CmdSN 0x17ab3 from world 16448 to dev "naa.60030d9088880a062f0e49b6ec181c95" failed H:0x7 D:0x2 P:0x0 Possible sense data: 0x6 0x29 0x0.


Stört Euch bitte nicht an der zeitlichen Differenz von 2h. Das ist noch ein Problem, das auf den ESX Hosts von mir behoben werden muss.

[Dayworker]

Bezüglich der Zeitdifferenz wirst du dir wohl keine Sorgen machen müssen, der ESXi läuft immer auf UTC. Lediglich der vSphere-Client rechnet die Zeit in die Zeitzone des Clients um.

[MarcelMertens]

Ne, im programmverzeichnis gibt es eine .exe oder .msc datei für die trace console (die man bei san melodey noch direkt aus dem program starten konnte). Dcstrace.exe oder ähnlich. Dort sieht man noch viel genauer die logs der dcs ports

[nikzin]

@marcelmertens: Es gibt eine dcstraceconsole.mmc und eine dcstrace.exe.

@dayworker: Danke für die Info.

[MarcelMertens]

dcstraceconsole.mmc ist die richtige. Von den ggf. Auftretenden .net fehlermeldungen nicht irritieren lassen. Geht trotzdem.

[kastlr]

Hallo Nick,

verwendest du beim Zoning auch die PWWN's für die Initiator und Targets?
Ich habe nämlich schon komische Effekte gesehen, wenn die NWWN's verwendet wurden.

Prinzipiell sollten CNA's beim Initialisieren einen SCSI Bus nicht reseten.
Wenn du nicht aus dem SAN bootest würde ich mal das CNA BIOS komplett disablen.

Viel Erfolg,
Ralf

[nikzin]

@marcelmertens: Ich habe mir die Traceconsole jetzt ein erstes Mal angesehen. Zurzeit kann ich noch keine entsprechenden Infos finden, aber ich muss mir die Konsole und die Traces nochmal im Detail ansehen. Danke für die Info.

@kastlr: Wir verwenden ein NWWN Zoning, sprich wir zonen anhand der WWNs der angeschlossenen Devices. Das haben wir bisher immer so gemacht. Das waren zwar in der Vegangeheit immer reine FC Umgebungen und SAN Switches von Cisco hatten wir bisher auch noch nie Verwendung (vorher Brocade un McData). Es traten aber auch noch nie Komplikationen, bei dieser Art von Zoning auf. Auch die involvierten Hersteller (Cisco, VMware, Datacore, Dell) haben bisher noch nicht darüber geklagt.
Die Einstellung "Boot from SAN" hatte ich testweise im CNA Bios deaktiviert. Es hatte aber nichts gebracht. Grundsätzlich hast du aber recht, dass es deaktiviert werden kann, wenn das OS auf dem Server installiert ist und nicht im SAN liegt. Mein eigentliches Problem wird damit aber nicht behoben.

Danke für die bisherigen Tipps...

[bla!zilla]

Single Initiator, Single Target ist eigentlich immer ein WWPN basiertes Zoning und so würde ich das auch immer machen. Zoning auf den WWNN kann Probleme machen, ist aber bei bestimmten Konstellationen notwendig. Ich würde es dahingehend anpassen.

[nikzin]

Damit ich von der gleichen Sache wie ihr auch:

WWPN: Zoning auf Basis der Port WWN des Switches.

WWNN: Zoning auf Basis der WWN des angeschlossenen Device.

Ist die Definiton so richtig ?

Wieso sollte eine Single Initiator/ Single Target auf WWPN basiertem Zoning beruhen ? Welche Probleme können auftreten, wenn ein WWNN Zoning verwendet wird ?

Mich wundert ein bißchen, dass der Cisco Support das Zoning in noch keinster Weise angesprochen hat.

[MarcelMertens]

Nein, eigentlich nicht. Beides ist WWN Zoning.

WWNN -> World Wide Node Name (der Karte)
WWPN -> World Wide Port Name (des Ports auf der FC Karte).

Ein QLA2562 hat einen WWNN und zwei WWPN (Dual Port)

[nikzin]

Okay, dann haben wir aneienander vorbeigeredet.

Wir haben auch ein WWPN Zoning, d.h. wir zonen anhand der Port WWN eines CNA/ HBA Adapter und nicht anhand der WWN der Karte.

Sorry für das Missverständnis.

[kastlr]

Hallo,

nein, folgende Definition ist korrekt.
Die WWPN entspricht der physikalischen WWN eines HBA Ports.
Beim Einsatz multipler HBA's in einem Host hat jeder HBA Port eine eigene WWPN und das Zoning sollte auch diese WWPN's verwenden.

Die WWNN ist die Node WWN.
Die WWNN wird für jeden Host aus der WWPN des HBA's generiert, die sich beim Name Server des Switches als erste HBA dieses Hosts meldet.
Die WWNN ist somit für alle HBA eines Host innerhalb einer SAN Fabric identisch.

Allerdings hast du vermutlich nur zwei CNA's in unterschiedlichen Fabrics, daher wirst du in dieses Problem gar nicht laufen können.

Gruß,
Ralf

[nikzin]

Wir haben definitiv ein WWPN Zoning.

Sorry für die Verwirrung, mein Fehler.

[nikzin]

Hallo zusammen,

so, nach unzähligen Stunden Troubleshooting konnten wir das Problem lösen.

Im CNA Bios (es schimpft sich fast!UTIL) existiert eine Einstellung, die "Host Adapter Bios" heißt. Sie steht default auf "Enabled". Die Funktion bedeutet nichts anderes als "Boot from SAN". Sobald diese "disabled" ist, wird kein Bus Reset mehr in der Umgebung ausgeführt.

Zwei Punkte find ich in diesem Zusammenhang interessant:

1. Ist ein Bus Reset in der gesamten Umgebung das normale Verhalten, wenn "Boot from SAN" aktiviert ist oder werden hier Befehle von Qlogic falsch gesendet bzw. von Nexus und/ oder Datacore falsch interpretiert. Ich persönlich habe keine Ahnung von "Boot from SAN", weil ich bisher das OS immer lokal auf den Hosts installiert habe. Vielleicht kann jmd. von Euch dazu etwas sagen ???

2. Ich habe im auf der Qlogic HP ein BIOS Doku zu FC HBAs gefunden. Hier steht, dass zumindest bei Qlogic HBAs (nicht CNAs) diese Funktion default auf "disabled" steht. Da die von uns verwendeten CNAs (QLE8262) Dell OEM branded Adapter sind, wäre es interessant zu wissen, ob diese Einstellung nur bei Dell OEM branded Adapter auf "enabled" steht. Diese Frage hab ich mal an Dell weitergeleitet, allerdings warte ich hier noch auf Feedback. Vielleicht hat jmd von Euch Qlogic CNAs (zB QLE8242) im Einsatz und könnte mir verraten wie die Einstellungen sind.

Jedenfalls vielen Dank für die vielen Tipps.

Jetzt kann ich endlich mit der Migration der VMs beginnen...

Viele Grüße,
Nick

[MarcelMertens]

1. Ist ein Bus Reset in der gesamten Umgebung das normale Verhalten, wenn "Boot from SAN" aktiviert ist oder werden hier Befehle von Qlogic falsch gesendet bzw. von Nexus und/ oder Datacore falsch interpretiert. Ich persönlich habe keine Ahnung von "Boot from SAN", weil ich bisher das OS immer lokal auf den Hosts installiert habe. Vielleicht kann jmd. von Euch dazu etwas sagen ???

2. Ich habe im auf der Qlogic HP ein BIOS Doku zu FC HBAs gefunden. Hier steht, dass zumindest bei Qlogic HBAs (nicht CNAs) diese Funktion default auf "disabled" steht. Da die von uns verwendeten CNAs (QLE8262) Dell OEM branded Adapter sind, wäre es interessant zu wissen, ob diese Einstellung nur bei Dell OEM branded Adapter auf "enabled" steht. Diese Frage hab ich mal an Dell weitergeleitet, allerdings warte ich hier noch auf Feedback. Vielleicht hat jmd von Euch Qlogic CNAs (zB QLE8242) im Einsatz und könnte mir verraten wie die Einstellungen sind.

Jedenfalls vielen Dank für die vielen Tipps.

Jetzt kann ich endlich mit der Migration der VMs beginnen...

Viele Grüße,
Nick

Zu Punkt 1: AFAIK sendet jeder Controller von dem gebootet werden soll/kann ein Bus Reset. Dieses ist ein normales Verhalten des Controllers. (Daher empfiehlt DataCore hier auch einen dedizierten FrontEnd Port für W2K3 Cluster Server).

Zu Punkt 2: AFAIK gibt es keine "Dell Branded" HBAs. Dell verbaut Standard QLogic Hardware und verwendet auch die Standard BIOS (Anders als z.B. HP)