Mask a datastore using Claimrules

I’m not sure how often you are getting these types of tasks in your environment as day to day activities. To be honest I got chance to Mask my VMFS datastores from vSphere level only one or two times. There was a storage migration and we had to mask datastores from the vSphere level just to avoid APD and PDL situations. That’s where I used these claimrules to mask my VMFS datastores.

I believe you are aware of these VMware claim rules and SATP rules. We used these rules to tag non-SSD disks as SSD disks in one of my previous posts. PSA (Pluggeble Storage Architecture) uses claimrules to determine the whcih multipathing module to use to make the connection to a certain device such as LUNs.

The over view of the Path selection plugins and where to fit these claimrules can be explained as below.

Here I’m using core claimrules to mask my datastore. Previously, I explained how to configure multipathing for iSCSI Storage and here I use one of my iSCSI datastore for this task, what it means for this datastore there are two paths and I’m going to mask both paths from two core claimrules.

This is how my iSCSI network look like and there are two port groups and each port group use different active physical interface to maintain the multipathin and high availability. You can view my multipathin post from here.

I’m going to mask “VMFS-3-DS03” datastore from these claimrules

Note: If it is difficult to see the outputs, click on the Image for a better view.

First of all you can view all the existing claimrules from “esxcli storage core claimrule list” command

Use “esxcfg-scsidevs -m” command to view and list all the devices along with the datastore names and device IDs. I have highlighted the device which I’m going to mask.

Once we identify the device we need to check what are the paths allow to access this device to this ESXi host. Type “esxcfg-mpath -L | grep <device ID of the datastore>” and identify the vmhba paths from the output. In my case “vmhba33:C1:T5:L0” and “vmhba33:C0:T5:L0” are the paths are visible to the ESXi host and we need to mask these two paths.

You can use “esxcfg-mpath -b -d <device ID of the datastore>” to get few more details, it is similar to the above output. Now we are going to add the cliamrule to mask one of the path using “MASK_PATH” plugin. Let’s do one after the other.

Type “esxcli storage core claimrule add –rule <rule id> -t location -A vmhba33 -C 1 -T 5 -L 0 -P MASK_PATH” command.

There are few parameters I used to create the command.

rule id – you need to use one of the rule ID which is not used in the list. Please find the below rule ID definitions

0 – 100 – reserved for VMware internal usage
101 – 65435 – for general use, you need to select one of the ID from this range (I used 105)
65436 – 65535 – reserved for VMware internal usage

-t – refers to the “Target” and we are going to point the location as the target. You can get more information from this KB article. You need to point the device using these switches.
-A – refers to the Adapter
-P – refers to the Plugin , I used “MASK_PATH” plugin to mask the device

Check the rule list whether your rule is in the list, you will be able to see the rule now. To view use “esxcli storage core claimrule list” command again

Now load the claimrule , use “esxcli storage core claimrule load”

Check and confirm the run time rule again

Unclaim all paths of the device and then run the loaded claimrules to reclaim them. Unclaiming disassociates the paths from a PSA plugin. These paths are currently owned by NMP plugin. You need to dissociate them from NMP and associate them to MASK_PATH plugin which we specified here.

Type “esxcli storage core claiming reclaim -d <device id>”

Type “esxcli storage core claiming unclaim -d <device id> -t location” command and it will give you an error message but don’t worry.

Type “esxcli storage core claimrule run” to run the new associations

That’s all now, rescan your HBA and see the Datastore availability.

Oops! it’s still there.. That’s where my iSCSI multipathing comes in to play. check the device paths using “esxcfg-mpath -L | grep “<device ID>”. There should be only one path available.

Do the same steps to mask this path to the ESXi Server. You need to use a different rule ID for this I used 106 as the second rule ID.

Rule list output should be like this

Once you successfully completed the above tasks check the datastore availability. Now you won’t be able to see the Datastore anymore.

Check the visible devices and ESXi host won’t see the device

Remove Core Claimrule and Remove the masking

Now we need to remove the claimrule and remove the masking. To remove the rule type “esxcli storage core cliamrule remove –rule 105” and load the claimrule using “esxcli storage core claimrule load”