Knowledge Base

• 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.

• Upgrade to ESX 3.5 Update 5 — ESX 3.5 Update 5 resolves the issue where ESX host machines take a long time to reboot.
  
• 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).