Paul Morrissey

VMware Native Multipathing rules for Hitachi VSP now enabled by default in vSphere builds

Blog Post created by Paul Morrissey Employee on Nov 30, 2018

A lengthy title but the following is long overdue for our customers. In the most recent releases of vSphere 6.7 and vSphere 6.5, VMware has now included default multipathing claim rules for Hitachi VSP Storage.


As a refresher, most customers had to manually add the following SATP rules when configuring multipathing (specifically path selection (PSP) and path failover (SATP) rules for Hitachi devices) on every ESXi host. Now these rules are included out of the box in vSphere 6.7U1 and vSphere 6.5 P03 (GA today, Nov 30th 2018) builds or later. This further reduces the time to production usage when deploying new vSphere ESXi hosts/clusters connected Hitachi Storage or as part of Hitachi UCP converged offering. The rules will handle devices configured with or without ALUA with ALUA typically being used for active-active (GAD) configurations.


The following are the recommended rules and what is now baked into vSphere builds


esxcli storage nmp satp rule add -V HITACHI  -P VMW_PSP_RR -s VMW_SATP_ALUA -c tpgs_on -e "Hitachi VSP Storage with ALUA enabled"

esxcli storage nmp satp rule add --satp "VMW_SATP_DEFAULT_AA" -V HITACHI -P "VMW_PSP_RR" -e "Hitachi VSP Storage"


We kept the IO Operations Limit to the default of 1000 as every site has some uniqueness. This may differ from other vendors recommendations (some who recommend 1) but that low a value would spoil the sequential detection handling within the VSP array and you might lose some performance from increases in random port behavior. More tests in this area to follow but wouldn't go below value of 20 if you do want to tweak where you have smaller number of LUNs and a high number of paths based on some initial informal testing.


Here is the typical output you should see on fresh install.  Note rules are "system" and no longer "user"


[root@localhost:~] esxcli storage nmp satp rule list |grep -i Hitachi

VMW_SATP_ALUA                        HITACHI   OPEN-V   system      tpgs_on                  VMW_PSP_RR            Hitachi VSP Storage with ALUA enabled                              

VMW_SATP_DEFAULT_AA          HITACHI                     system      inq_data[128]={0x44 0x46 0x30 0x30}  VMW_PSP_RR                                                                                

VMW_SATP_DEFAULT_AA          HITACHI   OPEN-V    system      tpgs_off                 VMW_PSP_RR             Hitachi VSP Storage                                                      

VMW_SATP_DEFAULT_AA          HITACHI                     system           


If you want to check what SATP/PSP is being claimed by a device (datastore LUN),  use the following command


[root@localhost:~] esxcli storage nmp device list


   Device Display Name: HITACHI Fibre Channel Disk (naa.60060e800727200000302720000002aa)

   Storage Array Type: VMW_SATP_ALUA

   Storage Array Type Device Config: {implicit_support=on; explicit_support=off; explicit_allow=on; alua_followover=on; action_OnRetryErrors=off; {TPG_id=7,TPG_state=AO}{TPG_id=4101,TPG_state=AO}}

  Path Selection Policy: VMW_PSP_RR

   Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0; lastPathIndex=1: NumIOsPending=0,numBytesPending=0}

   Path Selection Policy Device Custom Config:

   Working Paths: vmhba3:C0:T0:L0, vmhba2:C0:T0:L0


if you want to check the paths, [root@localhost:~] esxcli storage core path list

   Runtime Name: vmhba3:C0:T0:L1

   Device Display Name: HITACHI Fibre Channel Disk (naa.60060e800727200000302720000002ab)

   Adapter: vmhba3

   Channel: 0

   Target: 0

   LUN: 1



So another step to improve time to value and out of box best practice reliability in your VMware ecosystems with Hitachi Infrastructure. As parting thought and for upcoming blog, did you know latest release of UCP Advisor can perform that ESXi deployment from scratch (on supported compute) to take this time to value to the next level..


[update] If you want more information on claimrules, I found the following VMware online document useful