VMware Path Masking

October 30, 2012 0 By Eric Shanks

I’ve written posts in the past regarding LUN masking on a storage array, but it is possible to mask a path directly from your vSphere environment. I feel that if at all possible the masking should be handled at array level because the array is closest to the disk. Let’s face it, if vSphere shouldn’t see a LUN for one reason or another, then why is the array presenting it in the first place?

But for the purposes of this post we’ll assume that we’re unable to contact the storage team or the array itself is somehow unable to mask a path. vSphere can mask a path for you in the Pluggable Storage Architecture.

Let’s take a look at how this can be accomplished. In my home lab you can see that I have a small datastore named TEST_PSA which we’ll mask.

If we go into the properties we’ll see the runtime name, which is how I’ll identify this LUN to be masked. Please take note that there are more ways to identify devices other than the runtime name. You could for instance mask all paths that are presented from an EMC array by using a vendor identifier.

You can also gather more information from your devices by using the esxcli commands provided by VMware.

[sourcecode language=”PowerShell”] esxcli storage core device list [/sourcecode]

Now we need to find an open claimrule to be used.

[sourcecode language=”PowerShell”] esxcli storage core claimrule list [/sourcecode]

The list shown above is a set of rules on what to do with storage devices that are found by ESXi. Since we want to mask a device, we need to add a new rule. I can see from this list that rule 102 is not being used so let’s use this.

So now let’s create our rule.

[sourcecode language=”PowerShell”] esxcli storage core claimrule add -r 102 -t location -C 0 -T 3 -L 0 -P MASK_PATH [/sourcecode]

To breakdown this command we added rule 102 (-r 102) type location (-t location) device C0:T3:L0 (-C 0 -T 3 -L0) and plugin MASK_PATH

Once the command has been run we can view the claimrules again and we’ll notice that a new rule has been added.

This is not the end of the configuration however, the class is of type “file”. This means the rule has been created, but not yet enabled. To get it up and working, we need to load the rules and then run them.

[sourcecode language=”PowerShell”] esxcli storage core claimrule load [/sourcecode]

Now we can see that the class is of type “runtime” so it’s now active.