LUN Masking VMware ESXi host

I was recently looking up for topics to write on and I found an interesting bit of information related to LUN masking VMware ESXi host.

LUN masking is a process wherein you would mask LUNs, or make those LUNs inaccessible to the VMware ESXi hosts.

This needs to be performed on individual ESXi hosts using something called claimrules.

Now ideally, I haven't seen any administrators perform this action on ESXi hosts, but rather perform the LUN masking from the storage array side.

All the storage admins will be fairly clear with how this works from the storage array side. Usually, there would backend tool provided by the storage vendor which will allow you to present and unpresent LUNs to the ESXi hosts for a VMware environment.

With that being said, it is still a good to know information for any VMware Administrator if they need to test their skills and want to perform this in their lab environment.

Alright, now let us move to the actual content of the article where we will perform LUN masking VMware ESXi hosts.

First off, we need to decide on which LUN would you want to mask.

There are a couple of ways that you could find the number of LUNs visible to the ESXi hosts, one from the command line and other by connecting directly to the host using the vSphere Client.

Once you have decided on the LUN, we are interested in the LUN identifier, which is unique to every LUN and will be used to fetch more information about the LUN.

An easy way to list all the devices visible to the ESXi host using the below command.

esxcli storage core device list | less

I just piped the output to less so that we can view the contents one page at a time.

And once you have decided the LUN that you want to mask and want to see the information only about that LUN, use the below command.

~ # esxcli storage core device list -d t10.F405E46494C4542596D477279794D24364A7A4D233F69713

where the last part is the LUN identifier. Note that since this is a lab environment we are seeing the LUN id start with t10. In most cases, it would start with naa. followed by a series of alphanumeric value.

The output will be similar to the below image:

Now that we know which LUN to mask, we will have to decide on how to mask this LUN on the ESXi host.

Well, there are several ways that one can perform LUN masking VMware ESXi host. They are:

• Mask by path. (This will be the most commonly if you want to mask a single LUN)
• Mask by transport type. (You will use this when you want to mask one type of connection like iSCSI or Fibre Channel)
• Mask by Vendor. (This will be used when you want to mask all the LUNs from a specific storage vendor like EMC or Dell)

Now that we know the various mechanisms to mask the LUN, in our example, we will be using the first type, which is mask by path.

Like I said before, we will be using something called claimrules to perform this action, let us first take a look at the current claimrules on the ESXi host.

Use the below command to list the claimrules.

~ # esxcli storage core claimrule list

Now to list the paths currently used by the LUN that we want to mask, let us run the below command.

~ # esxcfg-mpath -m | grep t10.F405E46494C4542596D477279794D24364A7A4D233F69713

Ideally, you would see more than one path in your production environment since this is a lab environment, I have just configured one path.

Now, in order to mask this LUN, we will need to write a claimrule.

We will need an ID number in order to create the rule. We will also need to pass certain arguments to successfully create the rule which I am listing below:

• -r : ID number or rule number
• -t : Type (There are three options location for a path, vendor, and transport for a type of connection)
• -A : HBA adapter.
• -C : Channel
• -T : Target
• -L : LUN number
• -P : Plugin type (Mask_Path, NMP etc)

Therefore, with the information fetched with the previous command, our claimrule should look something like this.

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

We are making progress, now if you list the claimrules again, you would see that our newly created is listed but we will have load the rule before we could perform any further action.

~ # esxcli storage core claimrule load

Now we are almost there. Now the rule is loaded, but we have to reclaim the device for the rule to apply for which we will use the below command.

~ # esxcli storage core claiming reclaim -d t10.F405E46494C4542596D477279794D24364A7A4D233F69713

Voila, that's it! This LUN will no longer be visible to the ESXi host from now on.

If you would like to check that you were successfully able to reclaim the device, then you can use the below command and if the result is empty that means if you have reclaimed the device.

~ # esxcfg-scsidevs -m | grep t10.F405E46494C4542596D477279794D24364A7A4D233F69713

Now for whatever reason, let us say that you would require the LUN back. Well, not to worry, by just removing the claimrule and unclaiming the device you will be able to see the LUN again on the host.

To remove the claimrule, you will use the below command.

~ # esxcli storage core claimrule remove -r 300

Once the claimrule is removed, load the claimrules again to completely remove the rule from runtime.

~ # esxcli storage core claimrule load

Now run an unclaim command on our path. This will allow the path to be reclaimed by the default plugin.

~ # esxcli storage core claiming unclaim -t location -A vmhba33 -C 0 -T 3 -L 0

Now if you perform a rescan of the HBA adapter, you should be able to see the device back. To perform a rescan from the command line, you could use the below command.

~ # esxcfg-rescan vmhba33

That's it! We saw both how to mask and unmask the LUN in this article and I have thoroughly enjoyed writing this article. I hope this has been informative and thank you for reading!