Knowledge Base

The VMware Knowledge Base provides support solutions, error messages and troubleshooting guides

Search the VMware Knowledge Base (KB)

View by Article ID

SCSI reservation conflict errors reported on all hosts at the same time, with one host reporting the error: remote port time out

SCSI reservation errors are reported on all ESX hosts at the same time
The SCSI reservation errors appear similar to:

vmkernel: 0:17:26:38.886 cpu4:4274)ScsiCore: 1181: Sync CR (opcode 28) at 928 (wid 4110)
vmkernel: 0:17:26:39.310 cpu1:4116)ScsiCore: 1181: Sync CR (opcode 16) at 992 (wid 0)
The HBA reports the error:

NO_CONNECT
The QLogic driver for a single HBA on only one ESX host reports that the the remote port (rport) to which the HBA is connected went offline at the same time as or shortly after the SCSI reservation:

vmkernel: 0:15:16:31.245 cpu2:4212)<3> rport-4:0-5: blocked FC remote port time out: saving binding
vmkernel: 0:15:16:51.997 cpu3:4213)<3> rport-4:0-2: blocked FC remote port time out: saving binding
vmkernel: 0:15:16:51.997 cpu3:4213)<3> rport-4:0-3: blocked FC remote port time out: saving binding
vmkernel: 0:15:18:13.120 cpu5:4210)<3> rport-4:0-4: blocked FC remote port time out: saving binding
vmkernel: 0:15:22:16.459 cpu2:4207)<3> rport-4:0-0: blocked FC remote port time out: saving binding
vmkernel: 0:15:22:16.459 cpu4:4211)<3> rport-4:0-1: blocked FC remote port time out: saving binding

The HBA error NO_CONNECT indicates that the connection is lost for all paths for a single HBA on a single host. This loss of connection can occur if:

The physical port on the switch that the HBA is connected to goes into an error state. If this occurs, you are still physically connected to the switch but cannot talk to the targets on the other ports on the switch.
The adapter on the ESX host goes into an internal fatal error state. This leaves the adapter logged into the fabric but not functioning, which means that it can send out an SCSI reserve for a LUN but is not able to send a release. Since the adapter is still logged into the fabric, the array does not timeout the reserve sent by the host.

This is the most likely cause for the outage.

The LUN remains reserved until:
- A LUN reset is sent to the LUN by another ESX host or from the array side. The LUN reset breaks any existing reservations.
- The host with the HBA that had the reserve is rebooted. The HBA logs out of the fabric and the array automatically releases the LUN.

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

1 2 3 4 5

1 2 3 4 5

Actions

Did this article help you?
This article resolved my issue. This article did not resolve my issue. This article helped but additional information was required to resolve my issue.
What can we do to improve this information? (4000 or fewer characters)