VMware vSphere Blog

### Masking LUN paths using PowerCLI (Tested on ESXi 4.1)

Connect-VIServer -Server MyESX -Protocol https -User root -Password password!!

$esxcli = Get-EsxCli
$esxcli.nmp.path.list() | Select Device, RuntimeName | Sort RuntimeName

naa.6005nnnnnnnn0019 vmhba34:C0:T0:L0

$esxcli.nmp.path.list("naa.6005nnnnnnnn0019")

$esxcli.corestorage.claimrule.list()

$Prule=157
$Padapter="vmhba34"
$Pchannels=0,1
$Ptargets=0,1
$Pluns=0,1,2
ForEach ($Plun in $Pluns) {
ForEach ($Pchannel in $Pchannels) {
ForEach ($Ptarget in $Ptargets) {
Write-host "Add Rule: " $Prule " for "$Padapter":C"$Pchannel":T"$Ptarget":L"$Plun

$esxcli.corestorage.claimrule.add($Padapter,$null,$Pchannel,$null,$null,$null,$null,$Plun,$null,"MASK_PATH",$Prule,$Ptarget,$null,"location",$null)
$esxcli.corestorage.claimrule.load()
$esxcli.corestorage.claiming.unclaim($Padapter,$Pchannel,$null,$null,$null,$Plun,$null,$null,$null,$Ptarget,"location",$null)
$esxcli.corestorage.claimrule.run()

$Prule++
}
}
}
$esxcli.corestorage.claimrule.list()

--> Perform LUN masking at the storage level

### Unmasking the path
$Prule=157
$Pluns=0,1,2
ForEach ($Plun in $Pluns) {
ForEach ($Pchannel in $Pchannels) {
ForEach ($Ptarget in $Ptargets) {
Write-host "Delete Rule: " $Prule " for "$Padapter":C"$Pchannel":T"$Ptarget":L"$Plun

$esxcli.corestorage.claimrule.delete($null,$Prule)
$esxcli.corestorage.claimrule.load()
$esxcli.corestorage.claiming.unclaim($Padapter,$Pchannel,$null,$null,$null,$Plun,$null,$null,$null,$Ptarget,"location",$null)

$Prule++
}
}
}
$esxcli.corestorage.claimrule.run()
$esxcli.corestorage.claimrule.list()

Specific to ESXi4.1, is the procedure same while decommissioning the storage. We are decommissioning existing datastore. We will storage vMotion our VMs to new Datastores. If you could please clarify.

Also according to KB:1015084 I've not understood last section.
"Run this command to unclaim each path to the masked device:
# esxcli corestorage claiming unclaim -t location -A vmhba0 -C 0 -T 0 -L 2

This ensures that all paths to the device are unclaimed successfully before running the claim. Update vmhba, controller, target and LUN number as required."

Why I have to unclaim the path when device is never going to in?

How does this relate to using RDM? I wrote back in 2009 how annoying vSphere 4.1's new "intelligence" was with regards to removing LUNs (in my case RDMs) and re-adding them (I did this for SAN based snapshot stuff).
http://www.techopsguys.com/2009/08/18/its-not-a-bug-its-a-feature/

I have worked around the "feature" by using iSCSI directly in the guests bypassing vSphere entirely, this is not an ideal solution when I have hardware accelerated fibre channel available to every system.

Basically my process was:
1) unmount RDM from within guest
2) remove LUN out from under ESX
3) delete snapshot assigned to LUN
4) create new snapshot
5) create new LUN (same number as before)
6) export to ESX
7) re-mount volume in guest (i.e. no unmapping from guest, no guest reboot/shutdown etc)

This was part of an automated process that would take a R/W snapshot from say a production Oracle or MySQL database and swing it around to another system for use.

in ESX 3.0 and 3.5 this worked flawlessly hundreds of times, in vSphere 4.0 (haven't tried 4.1 or 5.0 yet) this broke because vSphere assigned a new UUID to the new snapshot even though it was on the same LUN # with RDM! The docs for RDM explicitly state RDM is good for leveraging SAN snapshots and/or for doing backups, both of which I leveraged this ability with, and it broke horribly in 4.0. vSphere should stay out of trying to micro manage RDMs because they are just that - raw devices.

I had similar UUID troubles (which I document in the above post) when dealing with NFS as well since vSphere 4.0 (again haven't tried 4.1 or 5.0 yet) assigned a UUID based on the IP address of the NFS cluster (of which there was many), so if I relied upon DNS to access my NFS (which seems common) I could not do things like vMotion because host #1 may be using IP #1 and host #2 may be using IP #3 and vSphere would see those different IPs as different UUIDs (even though it is the same file system, same NAS cluster), and prevent vMotion from occurring.

Can you revise your post to include instructions on how to do the same thing with RDM ? Preferably something that is simple.

I filed support cases on both of these issues back in 2009 but got nowhere.

Maybe it will 'just work' in 4.1 and/or 5.0, though I'm not holding my breath based on what support told me back then.

thanks

In vsphere 5.0, It is worthwhile to note that prior to unmount using VC, it does a exhaustive check and only when everything checks out "Green" it will give you an option to proceed with the unmount.
Big thanks to the team on making this a easier task rather than going thru hoops (masking and stuff as in ESX 4.x).