Need to understand mask and unmask .., bcoz i have deleted some luns from an esx host and still i mable to see the same in Add Storage Wizard (SAN team also unmapped the same from their end, still i m able to see the same after rescanning all FC HBA) . need your asisstance , what will be my next course of action mask/unmask.
where do you see the LUN's which are removed from your SAN team, on the ESXi Server or on the vCenter Server?
vCenter does show a mixed output from real (live data) and database content.
So if you directly conect to one of your ESX Servers, do you still see the LUN's?
I assume that you have more than 1 ESX host and all are in cluster and centralized with vCenter.
So in this case :
1) Confirm from the Storage team wether they have disconnected the LUN only from 1 ESX host or from All the ESX host. (You need to disconnect from all the ESX host if you are looking from vCenter)
2) Login to that ESX server directly from where the LUN has been disconnected by your storage team. (Check and confirm wether you are able to see the LUN -- it will not show there ? )
yes u r right, i have one HA enabled cluster and 2 esx 4.1 hosts are the member of the same, SAN team has unmapped LUns from both esx hosts.
esx1 we are not able to see those luns but on esx2 we are still able to see those luns on "Add Storage Wizard" as well as On "Path" Tab where these LUNs status are dead.
Do let me know if anything else is need from my end which helps me to resolve the same.
Actually it is not possible, Kindly check with the Storage team wether they have unmapped the LUN's properly from both the host and disable zonning (if applied ). And from your side rescan the storage from esx2 and see r u getting it again.
You can also take a look at Unpresenting a LUN in ESXi 5.x and see ig you have missed any step
This problem occurs as we have not runned the following commands after deleting the datastore from an ESX hosts,
79 esxcfg-scsidevs --vmfs
80 esxcfg-scsidevs -l
82 esxcfg-mpath -L | grep eui.0017380014330071
83 esxcli corestorage claimrule add --rule 192 -t location -A vmhba5 -L 3 -P MASK_PATH
84 esxcli corestorage claimrule add --rule 193 -t location -A vmhba3 -L 3 -P MASK_PATH
85 esxcli corestorage claimrule load
86 esxcli corestorage claimrule list
87 esxcli corestorage claiming reclaim -d eui.0017380014330071
88 cat /var/log/vmkernel
found this logs in vmkernel
Aug 29 21:27:23 E65185 vmkernel: 688:08:40:42.610 cpu20:4128)WARNING: NMP: nmpUnclaimPath: Physical path "vmhba3:C0:T6:L2" is the last path to NMP device "Unreg istered Device". The device has been unregistered.
Aug 29 21:27:23 E65185 vmkernel: 688:08:40:42.639 cpu14:4126)ScsiPath: 3806: Plugin 'MASK_PATH' claimed path 'vmhba5:C0:T2:L2'
Aug 29 21:27:23 E65185 vmkernel: 688:08:40:42.652 cpu14:4126)ScsiPath: 3806: Plugin 'MASK_PATH' claimed path 'vmhba5:C0:T3:L2'
Aug 29 21:27:23 E65185 vmkernel: 688:08:40:42.656 cpu14:4126)ScsiPath: 3806: Plugin 'MASK_PATH' claimed path 'vmhba3:C0:T5:L2'
Aug 29 21:27:23 E65185 vmkernel: 688:08:40:42.656 cpu14:4126)ScsiPath: 3806: Plugin 'MASK_PATH' claimed path 'vmhba3:C0:T6:L2'
91 esxcli corestorage claimrule delete --rule 192
92 esxcli corestorage claimrule delete --rule 193
93 esxcli corestorage claimrule load
94 esxcli corestorage claimrule list
after running the above command now we have to instruct SAN team to unmap LUNs from an ESX Host, otherwise this kind of problem perists if we have a cluster and more than 1 host are member of the same and the same LUNs are mapped to all ESX host then we need to run above command so that we can sucessfully mask luns from an esx host.
mask luns means ... once we run the above mask luns comands , then esx host won't try to access those/these LUNs, if we won't run the above mask LUNs command then after deleting datastore ESX continously try to access those LUNs, hence it's necessary to mask LUNs from an ESX host.
Deleting a datastore from vCenter Server and subsequent unpresentation of the LUN containing that datastore is effective most of the time. However, in ESX/ESXi 4.x, removal of LUN(s) without masking the LUN causes the host to continuously retry access to the LUN, and leads to an All-Paths-Down (APD) condition on the host.