Knowledge Base

Search the Knowledge Base: |
Search the Knowledge Base: |
SCSI Reservation Failures on Hitachi USP or NSC Arrays
Details
VMware ESX 3.0.x, 3.5 or ESX 4.0 VMkernel Logs show SCSI Reservation errors similar to what is listed in Troubleshooting SCSI Reservation failures on Virtual Infrastructure 3.x and vSphere 4.0 (1005009) . The Hitachi USP or NSC (Tagmastore family) array exhibits high storage Port Utilization with low I/Os going through the port.
Solution
Storage PortFan-in Ratio
This is defined as the number of initiators sharing the same Storage Processor Port.
VMware recommends reducing the Fan-in Ratio if you encounter SCSI Reservation Failures.
-
VMware recommend using non-LUSE based LUNs for VMFS volumes.
-
If you are using LUSE based LUNs, make sure that the Microcode version on the array is at least 50-07-66-00/00 then enable Host Mode Option 19. See KB 3408142 for details. This applies to Virtual LUNs as well.
Queue depth, LUN-to-ESX ratio, LUN-to-VM ratio
Based on log and Fibre Channel trace analysis, one cause of this issue is that the Command Queue is exhausted.
Perform one of the following to workaround the issue:
-
Reduce the Queue Depth on each Server's HBA connected to that array.
-
Reduce the number of ESX hosts sharing a given LUN or set of LUNs on that array.
-
Reduce the number of virtual machines per LUN so that the possible number of hosts accessing a given LUN is reduced. For example, if you limit the number of virtual machines per LUN to 4, the highest number of ESX hosts running these virtual machines does not exceed 4 in a DRS/HA cluster.
Note: This option may result in using more LUNs of smaller sizes. The maximum number of LUNs accessible by a VMware ESX 3.x and ESX 4.0 is 256.
Recommended the Queue Depth setting on the HBA
Number of hosts sharing a LUN Queue Depth Value
8 2
4 4
2 8
As fewer hosts share a given LUN, the queue depth setting will be higher.
Note:VMware has not received similar reports for USP-V or USP-VM and the above does not apply to these models. The HBA Driver’s default Queue Depth should be sufficient.
How to change the Queue Depth?
Run the following commands at the ESX Server Console (or the RCLI for VMware ESXi 3.5).
QLogic HBAs:
-
Run the following command to identify the HBA's driver name:
# vmkload_mod -l | grep qla
The output appears similar to:
qla2300_707_vmw
-
Substitute the <driver_name> parameter below with the name from the above output. Substitute the nn parameter with the Queue depth value calculated above.
# esxcfg-module -s "ql2xmaxqdepth=nn" <driver_name>
# esxcfg-boot -b
# reboot
Emulex HBAs:
-
Run the following command to identify the HBA's driver name:
# vmkload_mod -l | grep lpfcdd
The output appears similar to:
lpfcdd_7xx
-
Substitute the <driver_name> parameter below with the name from the above output. Substitute the "nn" parameter with the Queue depth value calculated above
# esxcfg-module -s “lpfc0_lun_queue_depth=nn” <driver_name>
If you have 2 Emulex HBAs in the server, the command would be:
# esxcfg-module -s "lpfc0_lun_queue_depth=nn lpfc1_lun_queue_depth=nn" <driver_name>
# esxcfg-boot -b
# reboot
-
Hitachi USP and NSC provide access to physical LUNs (internal to the array) as well as Virtual LUNs whose physical LUNs are actually hosted on other arrays behind them (Externalized).
-
Physical LUN that is represented by a Virtual LUN must be on Tier 1 type physical disks (Fibre SCSI Disks or Fibre SAS Disks) and with minimum 10K RPM rating to provide best I/O performance.
-
LUSE LUNs should not be used with Virtual LUNs.
Keywords
Feedback
- KB Article: 1006001
- Updated: Aug 14, 2009
- Products:
VMware ESX - Product Versions:
VMware ESX 3.0.x
VMware ESX 3.5.x
VMware ESX 4.0.x
VMware ESXi 3.5.x Embedded
VMware ESXi 3.5.x Installable
VMware ESXi 4.0.x Embedded
VMware ESXi 4.0.x Installable

