Lun Pfade "Dead" = Management weg !??!

[andiwe]

Hi zusammen,

hatten heute morgen ein merkwürdiges Problem und ich weis nicht wo ich suchen soll um die Ursache des Problems zu finden. Vielleicht ist es ja eine Fehlkonfiguration - ich weis aber nicht wo.

Heute morgen waren 2 unserer 3 ESXi Hosts im Vcenter Disconnected. Die VMs bis auf eine liefen alle. Die LUN dieser einen VM (View Connection Server) war weggebrochen da das SAN beide Spiegel kaputt hatte (nur das eine Volume). Warum das im SAN passiert ist steht auf einer anderen Karte. Mich interressiert eigentlich primär die Reaktion der ESX.
Wieso konnte es zu Problemen des Managements kommen nur weil beide Pfade einer LUN weg waren?
Nachdem die Pfade wieder ok waren (Split Mirror und Rebuild) liesen sich die ESX auch wieder im vCenter connecten, vorher nicht.

Umgebung:
3x ESXi 4.1 Build 348481
angebunden an Datacore SanMelody 3.0.4.2 HA (2 Knoten) mit FibreChannel.
LUN sind alle ALUA aktiviert (VMW_SATP_ALUA) mit RoundRobin Policy (VMW_PSP_RR).
Umgebung ist komplett Redundant aufgebaut.

Wo kann ich in den ESX Logs suchen? Im hostd.log und vpxa.log find ich garnix.
Danke schonmal. Kann es ein Problem bei Round Robin sein - quasi by Design?

[Tschoergez]

Schau mal im vmkernel.log.
Ich tippe mal, dass die Verwaltung des ESX mit dem Schreiben von logeinträgen und versuchten Storage-Failovern so beschäftigt war, dass die Heartbeats zum vCenter zu lange gebraucht haben => Disconnect im vCenter.

viele grüße,
jörg

[andiwe]

Hi, ja danke,

das vermute ich auch, dass der APD (All paths death/down) Status nicht eintritt und permanent der Failover versucht wird.

NMP: nmpDeviceAttemptFailover: Retry world failover device "naa.60030d903031302d3033325f4553585f" - issuing command 0x41027e24ad40
NMP: nmpDeviceAttemptFailover: Retry world restore device "naa.60030d903031302d3033325f4553585f" - no more commands to retry
NMP: nmpDeviceAttemptFailover: Retry world failover device "naa.60030d903031302d3033325f4553585f" - failed to issue command due to Not found (APD), try again...
vmw_psp_rr: psp_rrSelectPathToActivate: Could not select path for device "naa.60030d903031302d3033325f4553585f
NMP: nmp_DeviceRetryCommand: Device "naa.60030d903031302d3033325f4553585f": awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.

Ist eben ein wenig störend wenn man erstmal über die lokale Konsole an den Host heran muss.