vDCA550-Objective 1.1–6-Understand and apply LUN masking using PSA-related commands

In vSphere, LUN masking is used to either block an ESXi host from accessing a storage device or prevent a host from using a storage path. When the LUN is masked, the storage processor blocks the ESXi host from communicating with the LUN. When the VM is created on the ESXi host, the virtual machine’s VMDK file is mapped to a SCSI adapter. Each VM will see only the virtual disks that are successfully presented to the VM’s SCSI adapter.

Best practice is to set up LUN masking on the storage array. The exam will only look at setting up LUN masking on the ESXi host using the vSphere CLI. 

When you power on an ESXi host or manually choose to rescan for storage devices, the ESXi host will send a signal down the physical bus paths and discover any storage available to the host. The ESXi host will then assign each storage device an MPP based on the claim rules listed in the /etc/vmware/esx.conf fle. 

First of all we have to decide which LUN we want to mask and then going to mask it. In my case I have created a dedicated LUN for LUNMasking Testing as highlighted below


Next step is to SSH to the ESXi host where your desired volume has been mounted. In order to implement LUN Masking you have to identifying which LUN you want to mask and then get his identifier. I already decided and showed in above Storage view screenshot.
But in order to find the identifier against your desired LUN you may run following command on ESXi CLI and get the Storage identifier

#esxcfg-scsidevs –m  (identifier of the desired LUN has been highlighted below)


Following is the target identifier “t10.F405E46494C45425837546174494D2958787E4D284248366”

There is another useful command which gave you more useful information.

 #esxcli storage core path list

I highlighted the two thing which I will need for configuration

Next Step is to do the masking. Claim rules can also be created based on the following options:

Vendor String— A claim rule can be set up using the Vendor string, which must be an exact match. An example would be vendor=DELL .

 Model String— A claim rule can be set up using the Model string, which must be an exact match. An example would be model=Universal Xport .

Transport type— A claim rule can be created to mask all LUNs based on the transport type. Valid transport types are block , fc , iscsi , iscsivendor , ide , sas , sata , usb , parallel , and unknown .

Driver type— A driver name is an option that can be used to create a claim rule.You can set up a claim rule masking all paths to devices attached to an HBA using a driver such as the iscsi_vmk driver.

Next step is first check the existing clamrules.

#esxcli storage core claimrule list 

NOTE: You can use any claim rule number that is not being used, with the exception of rules 0–100, which are reserved for VMware’s internal use. If you see above screenshot first rule is start with no 101.

In my demonstration I am going to do masking based on the path. In order to do it by path, we need to see all of the paths associated with our identifier. Run the below CLI command to find the paths.

#esxcfg-mpath –m |grep t10.F405E46494C45425837546174494D2958787E4D284248366



I have highlighted the path in Green color. Which is “vmhba33:C0:T0:L3”. In my case I have only one path. If you have multiple paths then you do the masking on all the paths associated with the identifier.

Now we have everything. Lest create/add a claim rule.run the below CLI command

# esxcli storage core claimrule add -r 110 -t location -A vmhba33 -C 0 -T 0 -L 3 -P MASK_PATH

If you don’t know the whole syntax then just press enter after (esxcli storage core claimrule add) CLI command. It will display you example of all type of rule. Just copy an example and then modify it according to your need.


Verify or list your claimrules. Now we can see below a newly added claimrule as highlighted.

#esxcli storage core claimrule list

This rule has not been implemented yet. We need to load then into the kernel by following CLI command (basically when we add the claim rule it will save in the file. You can see in “class” section in the above screenshot. When we run the load command its load it from file to kernel).

# esxcli storage core claimrule load (load rule from /etc/vmware/esx.conf file to kernel)

If your list the claimrule. You can see,  we have two rule one in “runtime” and other one in “file” class.

#esxcli storage core claiming reclaim –d t10.F405E46494C45425837546174494D2958787E4D284248366


Restart your ESXi host.

In case, if you don’t want to restart the ESXi Host (the procedure is mentioned in the book is not work for me).

NOTE: it will disassociate the paths from a PSA plugin. These paths are currently originally owned by NMP. You need to dissociate them from NMP and have them associated to MASK_PATH.


From CLI:

#esxcli storage core path list 

And find your LUN. In my case it’s highlighted below and its status is dead.


From GUI:

As you can see below “ISCSI_LunMasking_Testing” volume is not available in the list of storage.


Now we have implemented the claim rule. Let’s see how we get rid of them and remove the masking
#esxcli storage core claimrule remove –r 110 (remove the claimrule with ID 110)
#esxcli storage core claimrule load ( load the claimrule from the file)
#esxcli storage core claiming unclaim –t location –A vmhba 33 –C 0 –T 0 –L 3 (this will allow them to be reclaimed by the default plugin)


Rescan the storage and you will find your masked LUN back as shown below.
You may also see this article http://www.bluebox-web.com/2012/11/13/understand-and-apply-lun-masking-using-psa-related-commands/


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s