The VMware Knowledge Base provides support solutions, error messages and troubleshooting guides
ESX machines hosting passive MSCS nodes report reservation conflicts during storage operations (1009287)
- Rescanning for new storage takes a very long time to complete
- The VMware Infrastructure (VI) Client might report a timeout
- Using the Add Storage wizard results in the VI Client reporting a timeout
- Reboots take a very long time to complete
- The VMkernel logs show these errors:
SCSI: vm 1043: 5522: Sync CR at 64
SCSI: vm 1043: 5522: Sync CR at 48
SCSI: vm 1043: 5522: Sync CR at 32
SCSI: vm 1043: 5522: Sync CR at 16
SCSI: vm 1043: 5522: Sync CR at 0
WARNING: SCSI: 5532: Failing I/O due to too many reservation conflicts
WARNING: SCSI: 5628: status SCSI reservation conflict, rstatus 0xc0de01 for vmhba1:0:7. residual R 919, CR 0, ER 3
WARNING: J3: 1970: Error committing txn to slot 0: SCSI reservation conflict
Note: If you experience similar symptoms in ESX/ESXi 4.x, see ESX/ESXi 4.x hosts hosting passive MSCS nodes with RDM LUNs may take a long time to boot (1016106).
This issue may occur if:
The ESX host is hosting a passive Microsoft Cluster node. This includes ESX hosts that are exposed to the LUNs used for MSCS but have no virtual machines that participate in Microsoft clustering.
- The virtual machine configured for the Microsoft Cluster uses an RDM. This includes RDMs exposed to the virtual machine with virtual SCSI bus sharing set to either Physical or Virtual.
When ESX hosts a virtual machine in these scenarios, attempts by any ESX host (other than the one that is hosting the Active node) to conduct I/O to the LUNs used by the Microsoft Cluster results in an I/O error. This behavior is expected as the active Microsoft Cluster node maintains a SCSI reservation on the RDM LUNs.
This issue has been resolved or minimized with the following patches. If you have storage related problems in an environment with MSCS virtual machines, ensure all your ESX/ESXi hosts have these patches installed before applying any workaround. For more information about these patches, see:
- VMware ESX 3.5 Update 5, Patch ESX350-200911201-UG: Updates VMkernel, Service Console, hostd (1015045)
- VMware ESX 3.5 Update 5, Patch ESXe350-200911201-I-UG: Updates Firmware (1015045)
- VMware ESX 3.5 Update 5, Patch ESX350-200911202-UG: Updates ESX Scripts (1015026)
- VMware ESXi 3.5, Patch ESXe350-200910401-I-SG: Updates Firmware (1014761)
- VMware ESX 3.5, Patch ESX350-200910401-SG: Updates VMkernel, Tools, hostd (1013124)
- VMware ESX 3.5, Patch ESX350-200910402-BG: Updates ESX Scripts (1013125)
To workaround this issue:
- For ESX machines that host virtual machines that participate in Microsoft Clustering and virtual machines that are configured like the above scenarios, perform the Rescan/Storage addition on the machines hosting the active Microsoft cluster node. If you want to perform those operations on the other ESX machine hosting the Passive Microsoft Cluster node, make that node Active.
- For ESX machines that are exposed to the LUNs used by Microsoft Clustering and no virtual machine on these hosts are involved in MSCS, VMware recommends that you do not expose the LUNs used by MSCS to ESX hosts that are not part of the Cluster configuration.
Note: If a host is exhibiting these symptoms and does not host any of the MSCS virtual machine nodes, you may want to consider masking out the LUNs for these hosts. For more information on how to mask LUNs, see Making Masked LUNs Settings Persistent Across Reboots on ESX Server (2057).
Request a Product Feature
To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.