User guide

Technical white paper | HP Enterprise Virtual Array Storage and VMware vSphere 4.x and 5.x configuration best practices

Use the following command to verify that the new rule has been successfully added:

esxcli nmp satp listrules

Deleting a manually-added rule

To delete a manually-added rule, use the esxcli nmp satp deleterule command; specify the same options used to create the

rule. For example:

esxcli nmp satp deleterule --satp="VMW_SATP_ALUA" --psp="VMW_PSP_RR" --psp-

option="iops=1" --claim-option="tpgs_on" --vendor="HP" --model="HSV210" --

description="My custom HSV210 rule"

Caveats for changing the rules table

When making changes to the SATP rules table, consider the following:

• On-the-fly rule changes only apply to Vdisks added to the particular array after the rule was changed. Existing Vdisks

retain their original settings until a vSphere server reboot occurs or a path reclaim is manually triggered.

• The array vendor and models strings used in the addrule command line must exactly match the strings returned by the

particular array. Thus, if the new rule does not claim your devices – even after a server reboot – then verify that the

vendor and model strings are correct.

• As you add rules to the SATP rules, tracking them can become cumbersome; thus, it is important to always create a rule

with a very descriptive, consistent description field. This facilitates the retrieval of user-added rules using a simple filter.

Best practice for changing the default PSP in vSphere 4.1/5.x

• Create a new SATP rule for each array model.

Best practice for configuring round robin parameters in vSphere 4.x/5.x

• Configure IOPS=1 for round robin I/O path policy.

Caveats for multi-pathing in vSphere 4.x/5.x

This section outlines caveats for multi-pathing in vSphere 4.x associated with the following:

• Deploying a multi-vendor SAN

• Using Microsoft clustering

• Toggling I/O path policy options

• Using data replication (DR) groups

• Using third-party multi-pathing plug-ins

Deploying a multi-vendor SAN

In an environment where ALUA-capable arrays from multiple vendors are connected to the same vSphere 4.x cluster,

exercise caution when setting the default PSP for VMW_SATP_ALUA, especially if the arrays have different

recommendations for the default PSP option.

Setting the appropriate PSP differs depending on the deployment type.

vSphere 4 deployment

If the total number of EVA Vdisks is smaller than the total number of logical units from third-party arrays, then set the

default PSP option to VMW_PSP_RR, assuming that the third-party storage vendor(s) also recommend(s) this setting.

Otherwise, use the recommended default for the third-party arrays and manually configure EVA Vdisks. Thus, to minimize

configuration time, the bulk of the task is automatically performed by default using vSphere 4.x, leaving you to manually

run a simple script to set the desired PSP – VMW_PSP_RR – for EVA Vdisks.

The above recommendation only applies to the following use case:

• The EVA and third-party arrays are in the same vSphere 4 SAN

• Arrays from two or more vendors are ALUA-compliant

• There are different default recommendations for PSPs

vSphere 4.1/5.x deployment

• If the multi-vendor SAN is being shared by a vSphere 4.1 cluster, then create a new SATP rule entry for each array, setting

the configuration parameters as recommended by the particular vendor.