Active (I/O) paths misconfigured on VMware with ALUA

[#1]

Hello all,

I am seeing a strange behavior in as customer´s virtual environment. We have this vSphere 5.0 cluster which is accessing its Datastores via FCP. VSC 4.1 is installed and recommended settings are applied to the cluster. Igroups on the NetApp side have ALUA enabled.

On the vSphere side, path selection policy is round-robin and SATP is ALUA aware also (VMW_SATP_ALUA). There are 8 paths from each ESXi server to the NetApp HA pair (4 to each controller, running DOT 8.0.2P3 7-mode).

With this configuration we are seeing all paths as "Active (I/O)". Which for me indicates that all paths are active and I/O is passing through them all. I understand that with this configuration we would have 4 paths as "Active (I/O)" (optimized paths) and 4 paths as "Active" (non-optimized paths).

Does anyone know what could be possibly happening here? What's my mistake?

Kind regards,

Pedro Rocha.

[#2]

Please follow the KB on this issue:

https://kb.netapp.com/support/index?page=content&id=1011577&actp=search&viewlocale=en_US&searchid=null

[#3]

Hi Doug,

Have done that before, no success. Case opened, let's see what is happening. Will post here...

Regards,

Pedro Rocha

[#4]

Hi Pedro,

I'm having the exact same problem and also have a ticket open but it's been a few weeks and so far no luck. Were you able to get a resolution? My setup is almost identical except my DOT is 8.0.2P4 and ESXi servers are 5.1 (though I had this problem with vSphere 5.0 as well). What kind of SAN switches are you using if I may ask? Thanks!

Sergio

[#5]

Hi Sergio,

I have not got any answer yet. Case is still opened. We are using Brocade 5100 switches for the SAN environment.

I'll post here if I get any luck.

Regards,

Pedro Rocha.

[#6]

Hello Pedro,

we have the same Configuratiuon / Problem. We use a FAS3240 Ontap 8.1.2 7 Mode with FC and Brocade 200E 4GB. The Servers come from HP CX7000 Blade

On the vSphere side, path selection policy is round-robin and SATP is ALUA.

All 4 Path are (Active IO). When we do a "CF Takeover", we lost the communication HOST <-> Datastore. If we "cf giveback" all 4 Path will come back online.

We open a Case since 29.4.2013. ....we are waiting...

Regards

Werner Komar

[#7]

Werner,

We are now dealing with VMware. NetApp told us to contact them since the issue does not appear to be related to NetApp.

I'll tell you when we have something.

Regards,

Pedro

Pedro Rocha

+55 61 8203-5800

Enviado pelo meu BlackBerry®

[#8]

We had a similar issue with two FAS 3240 in a streched Metro Cluster using FC.

The solution for our environment was to disable ALUA on IGroup within the Netapp.

Then the ESX-Servers use default-ALU (VMW_SATP_DEFAULT_AA). Path Policy is set to Round robin (VMWARE).

Maybe this helps.

Regards,

ps-support

[#9]

Additional info:

you have to reboot the esx servers after disabling ALUA on the netapp, then the esx servers should use VMW_SATP_DEFAULT_AA  instead of VMW_SATP_ALUA.

Regards,

ps-support

[#10]

Has this been sorted out, I am running into this issue with 5.1 hosts and ALUA enabled iGroups. I can give more details if needed but I am basically just reaching out before we submit a ticket on this.

Message was edited by: Allan Howard Here's a nmp list -d for one of my datastores ~ # esxcli storage nmp device list -d naa.60a98000572d43504f5a636d57537144 naa.60a98000572d43504f5a636d57537144    Device Display Name: NETAPP Fibre Channel Disk (naa.60a98000572d43504f5a636d57537144)    Storage Array Type: VMW_SATP_ALUA    Storage Array Type Device Config: {implicit_support=on;explicit_support=off; explicit_allow=on;alua_followover=on;{TPG_id=2,TPG_state=AO}{TPG_id=2,TPG_state=AO}{TPG_id=2,TPG_state=AO}}    Path Selection Policy: VMW_PSP_RR    Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0;lastPathIndex=3: NumIOsPending=0,numBytesPending=0}    Path Selection Policy Device Custom Config:    Working Paths: vmhba2:C0:T1:L61, vmhba2:C0:T0:L61, vmhba3:C0:T0:L61, vmhba3:C0:T1:L61    Is Local SAS Device: false    Is Boot USB Device: false