Forcing the NMP Plugin for Microsoft Clustering LUNs on vSphere

While using Microsoft Clustering Service (MSCS) on Raw Device Mappings (RDMs) is a supported configuration on vSphere 5, using third party multipathing plugins is typically not. This usually isn’t a concern unless you’ve deployed some alternative multipathing plugin to your hosts, such as EMC’s PowerPath Virtual Edition (VE). If you still want to take advantage of a third party plugin, you always have the option of forcing specific LUNs in use by MSCS back to the Native Multipathing (NMP) plugin provided by VMware, which is fully supported. This post will go over the use of ESXCLI to change the PSA plugin to NMP with regards to specific LUN IDs.

Note: I’ve found a reference saying that the latest edition of PPVE should work. I suppose it’s up to you if you want to try that out.

Gather Device Information

You’ll need a few bits of information to get started. First, the NAA number for the MSCS owned LUNs you wish to change to NMP. This can be found in the vSphere client under Storage Adapters, or by using the command:

esxcli storage core path list

More details on this process are in this great VMware KB article.

Here’s an example. Notice that the information is redundant in a few places; I’ve highlighted the relevant data in red.,,t,0-naa.600140553a173f5de0fcd36d1d8847d2
Runtime Name: vmhba38:C0:T1:L2
Device: naa.600140553a173f5de0fcd36d1d8847d2
Device Display Name: SYNOLOGY iSCSI Disk (naa.600140553a173f5de0fcd36d1d8847d2)
Adapter: vmhba38
Channel: 0
Target: 1
LUN: 2
State: active

New Claiming Rules

With the NAA numbers and LUN IDs in hand, the next step is to create new claiming rules.

First, issue a command to list out the current rules:

esxcli storage core claimrule list

In this lab scenario, two of my vendors (WahlNwrk and Skittles) have a special third party plugin installed called WAHLNWRK. Any time the host finds a device made by these vendors, it will use the WAHLNWRK plugin instead of NMP. Unfortunately, the WAHLNWRK plugin is not supported by MSCS; we’ll have to change it to NMP for those specific LUNs.

My ficitious lab MSCS LUN IDs are 10 and 11. I’ll add a claimrule that sets those particular LUN IDs to NMP.

Since the WAHLNWRK rules are 250 and 251, I’ll need to use a lower number than that (but in the 200+ range) so that the NMP rule matches first. I’ll use rules 210 and 211 for my two LUNs, which is lower than 250 (the WAHLNWRK rules).

esxcli storage core claimrule add -r 210 -P NMP -t location --lun 10
esxcli storage core claimrule add -r 211 -P NMP -t location --lun 11

Then, load and run the rules so that they show up with a class of “runtime” (active) and “file” (in the conf file)

esxcli storage core claimrule load
esxcli storage core claimrule run

Now, the list should look like this:

However, you’re not done yet. The final step is to reclaim the devices so that they are switched over to NMP.

Remember that the NAA numbers will be specific to your environment.

esxcli storage core claiming reclaim -d naa.600140553a173f5de0fcd36d1d8847d2
esxcli storage core claiming reclaim -d naa.600140553a173f5de0fca36d1d581370


If you try to use an unsupported third party plugin, the MSCS will act very strange and often the disks will simply¬†disappear¬†or lose their drive letter. You’ll need to run the commands above on all hosts that the MSCS will be running on.

Here is a picture of the device connected to my lab.