ESX/ESXi 4.x
#esxcli nmp device list
NOTE: If I/O is active to a LUN and an attempt is made to modify the path policy, a failure can occur:
error during the configuration of the host: sysinfoException;
Status=Busy: Message=Unable to Set
If this problem occurs during an attempt to change the path policy, reduce the I/Os to that LUN and then try making the desired changes.
Performance Considerations for Multiple Host Configurations
The information in this section should be considered when using multiple ESX hosts, (or other hosts in conjunction with ESX hosts), that are connected in a
NOTE: For ESX 4.0 systems, HP recommends changing the ESX Scsi.ConflictRetries from its default value of 80 to a value of 200 when connected to an HP 3PAR StoreServ Storage running HP 3PAR OS version 2.2.4 or earlier. This change lengthens the time allowed for I/O retries due to ESX
You can change this value using the VMware ESX VI/vSphere client: In the ESX host, select the Configuration tab, select Advanced Settings for software, select Scsi, scroll to Scsi.ConflictRetries, and change the value in the field. Click OK to complete the change. A reboot is not required for the change to take effect.
This does not have to be done for ESX 4.1 or ESXi 5.x systems.
ESX/ESXi Handling SCSI Queue Full and Busy Messages from the HP 3PAR StoreServ Storage Array
VMware ESX Releases through ESX 3.5 Update 3
The default behavior of an ESX 3.5 update 3 and older servers to Queue Full and Busy SCSI messages from the HP 3PAR StoreServ Storage is to treat them as valid commands and to continue sending data. When continued outstanding commands are being sent to an HP 3PAR StoreServ Storage port, the port cannot recover and stops responding for attached hosts.
This type of action is critical where QLogic HBAs are used on the HP 3PAR StoreServ Storage because, when the storage port stops responding, the QLogic driver on the HP 3PAR StoreServ Storage has to issue a reset of the affected port.
The time in which the HP 3PAR StoreServ Storage port is at full capacity and the reset time of the port does not trigger a failover in the ESX host, since the ESX host never detects the port going away. This results in a virtual machine crash. There are two solutions:
•Upgrade to ESX 3.5 Update 4 or later.
•Control the IO that each array port receives by manipulating the HBA queue depth (see “Modifying the Tuneable Parameters for Queue Depth Throttling in ESX 3.x” (page 49)).
Performance Considerations for Multiple Host Configurations | 47 |
