Unsolved
This post is more than 5 years old
123 Posts
1
2954
Issue to be aware of before upgrading to ESXi 6.5
Per this VMWare KB article (2148265):
There is potential issue of losing access (data unavailable or DU) to some Datastores.
As the VMWare KB article states, you can see if you would be affected by this issue BEFORE upgrading by running some esx commands:
************************************************
# esxcli storage core device list
naa.6001f931059e80000113000200000000
Display Name: Fibre Channel Disk (naa.6001f931059e80000113000200000000)
Has Settable Display Name: true
Size: 10240
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/naa.6001f931059e80000113000200000000
[ … ]
Is VVOL PE: false
Is Offline: false
Is Perennially Reserved: false
Queue Full Sample Size: 0
Queue Full Threshold: 0
Thin Provisioning Status: unknown
Attached Filters:
VAAI Status: supported
Other UIDs:
vml.02000600006001f931059e80000113000200000000495345323430,
vml.02000800006001f931059e80000113000200000000495345323430
Note: Command output was reduced to improve clarity.
For example:
# esxcfg-mpath -b
naa.6001f931059e80000113000200000000 : Fibre Channel Disk (naa.6001f931059e80000113000200000000)
vmhba2:C0:T0:L6 LUN:6 state:active fc Adapter: WWNN: 20:00:00:25:b5:ab:00:4f WWPN: 20:00:00:25:b5:ac:00:3f Target: WWNN: 20:00:00:1f:93:10:59:e8 WWPN: 20:00:00:1f:93:10:59:e8
vmhba2:C0:T1:L6 LUN:6 state:active fc Adapter: WWNN: 20:00:00:25:b5:ab:00:4f WWPN: 20:00:00:25:b5:ac:00:3f Target: WWNN: 20:00:00:1f:93:10:59:e8 WWPN: 20:00:00:1f:93:10:59:ed
vmhba1:C0:T3:L8 LUN:8 state:active fc Adapter: WWNN: 20:00:00:25:b5:ab:00:4f WWPN: 20:00:00:25:b5:ac:00:2f Target: WWNN: 20:00:00:1f:93:10:59:e8 WWPN: 20:00:00:1f:93:10:59:e9
vmhba1:C0:T5:L8 LUN:8 state:active fc Adapter: WWNN: 20:00:00:25:b5:ab:00:4f WWPN: 20:00:00:25:b5:ac:00:2f Target: WWNN: 20:00:00:1f:93:10:59:e8 WWPN: 20:00:00:1f:93:10:59:ec
******************************
At this time, the above VMWare KB article is being shared with various Dell/EMC teams to determine an appropriate response.
FoolInTheRain
123 Posts
2
June 15th, 2017 11:00
For people who use PowerPath, this is an alternate way to determine if you have the same problem:
**********
another way to validate via PowerPath output (not sure how what Native Multipathing would look like). Below is an example of a problem Volume. Please note that this is a Vplex metro volume so the Path’s we see are coming from unique LUNs at either side of the Metro Cross-Connect setup:
Pseudo name=emcpower51
VPLEX ID=FNM00124600034 , FNM00124600033
Logical device ID=6000144000000010305AAE42DDAAF569
Standard UID=naa.6000144000000010305aae42ddaaf569 [dd_VFNM00153900816-c53424000b4_VFNM00153900749-c56470000b2_vol]
type=Conventional; state=alive; policy=ADaptive; queued-IOs=0
==============================================================================
--------------- Host --------------- - Stor - -- I/O Path -- -- Stats ---
### HW Path I/O Paths Interf. Mode State Q-IOs Errors
==============================================================================
2 vmhba1 C0:T1:L59 CL2-08 active alive 0 0
1 vmhba3 C0:T3:L58 CL1-0D active alive 0 0
2 vmhba1 C0:T0:L59 CL2-04 active alive 0 0
1 vmhba3 C0:T2:L58 CL1-01 active alive 0 0
1 vmhba3 C0:T1:L59 CL2-0D active alive 0 0
1 vmhba3 C0:T0:L59 CL2-01 active alive 0 0
2 vmhba1 C0:T3:L58 CL1-04 active alive 0 0
2 vmhba1 C0:T2:L58 CL1-08 active alive 0 0
Notice the I/O Paths above. The “L” value is the LUN ID and they are NOT equal. They have to be to avoid this situation.
Also notice the Stor – Interf. Where CL1 = Vplex Cluster1 of the Metro and CL2 = Vplex Cluster2 of the Metro.
**********
Murrieta
10 Posts
2
June 15th, 2017 23:00
Hi Jay,
Thanks for getting the word out to the community. I was affected by this change in a recent upgrade to ESXi 6.5. I have 8 datastores that are no longer visible to half of my VMware datacenter. With the help of your colleague Brian and your awesome team there at ViPR support, we were able to identify this issue and that ViPR-C version 3.6 supports HLU consistency. I just upgraded to ViPR-C 3.6 and verified that new datastores created in ViPR-C have consistent LUN numbers. With ESXi hosts that can still see the 8 datastores, I can Storage vMotion off the inconsistent HLU datastores and decommission them.