Take a look at the following screenshot-
How many disks are mapped or connected to this host?
If I then showed you this screenshot, would it change your mind?
LUN masking on ESXi goes against just about every best practice in the industry but it’s something to be aware of when troubleshooting storage; largely because it isn’t easily visible when implemented. The screenshot from the vSphere Web Client below shows a host that has had a LUN masked at the ESXi level. As you can see, there’s little to indicate that’s the case.
The clue is in the second screenshot above. In particular the following lines-
MP 200 runtime vendor MASK_PATH vendor=SYNOLOGY model=* false false 0 MP 200 file vendor MASK_PATH vendor=SYNOLOGY model=* false false 0
Rather annoyingly, there are no commands that can identify if a LUN is being masked. It’s up to the admin to look at claim rules, the storage being presented and do the math. So let’s back up a bit and first look at how to implement LUN masking on ESXi.
Setting up Claim Rules
I’ve wiped all advanced config on my hosts, presented a Synology LUN to ESXi and added a static target. We can rescan the adapter and confirm the LUN is visible-
esxcli storage core adapter rescan -A vmhba65
esxcli storage core device list | grep -i synology
This should give an output similar to the following-
Let’s give ourselves a reference point of what claim rules look like out of the box, with the following command
esxcli storage core claimrule list
This is from a fresh ESXi 6.5U2 install-
There are three selection criteria for masking LUNs, defined in ESXi as the type–
- Path – likely only used to hand pick a small number of LUNs
- Protocol – iSCSI, FC etc
- Vendor – storage hardware manufacturer
A number of arguments may be combined with the above to fine tune the LUN selection criteria and ultimately, create a claim rule. These are a few of the more likely candidates-
-A|--adapter=<str> Indicate the adapter of the paths to use in this operation. -u|--autoassign The system will auto assign a rule id. -C|--channel=<long> Indicate the channel of the paths to use in this operation. -d|--device=<str> Indicate the Device Uid to use for this operation. -D|--driver=<str> Indicate the driver of the paths to use in this operation. -i|--iqn=<str> Indicate the iSCSI Qualified Name for the target to use in this operation. -L|--lun=<long> Indicate the LUN of the paths to use in this operation. It must not be higher than the value of the advanced config option /Disk/MaxLUN -M|--model=<str> Indicate the model of the paths to use in this operation. -P|--plugin=<str> Indicate which PSA plugin to use for this operation. (required) -r|--rule=<long> Indicate the rule ID to use for this operation. -T|--target=<long> Indicate the target of the paths to use in this operation. -R|--transport=<str> Indicate the transport of the paths to use in this operation. Valid Values are: [block, fc, iscsi, iscsivendor, ide, sas, sata, usb, parallel, fcoe, unknown] -t|--type=<str> Indicate which type of matching used for claim/unclaim or claimrule. Valid values are: [vendor, location, driver, transport, device, target] -V|--vendor=<str> Indicate the vendor of the paths to user in this operation. --wwnn=<str> Indicate the World-Wide Node Number for the target to use in this operation. --wwpn=<str> Indicate the World-Wide Port Number for the target to use in this operation.
The type and claim rule ID (or -u flag) are both required along with the -P flag, which in order to mask paths will always be set to MASK_PATH.
So in order to mask all paths on my Synology NAS, I could run the following-
esxcli storage core claimrule add -r 300 -t vendor -V SYNOLOGY -P MASK_PATH
Reload claim rules
esxcli storage core claimrule load
Verify the claim rule was added
esxcli storage core claimrule list
You should end up with something that looks like this-
Find the device ID of the device to be masked
esxcli storage core device list | grep -i synology
Then remove and reapply claim rules for the device
esxcli storage core claiming reclaim -d naa.6001405c28c2bfdd3942d4e62d977dd9
Then check that the expected device is no longer present
esxcli storage core device list | grep -i synology
Removing Claim Rules
Undoing this is a similar process-
List all claim rules and take note of the ID of rules with plugin set to MASK_PATH
esxcli storage core claimrule list
Remove the appropriate claim rules
esxcli storage core claimrule remove -r 300
Reload claim rules
esxcli storage core claimrule load
Unclaim paths. I’m targeting the entire software iSCSI adapter
esxcli storage core claiming unclaim -t location -A vmhba65
Confirm devices are visible once again
esxcli storage core device list | grep -i synology