VMware Cloud Community
Hypnotoad
Contributor
Contributor

Create RDM for a VM

Hey All,

I'm a noob to Powershell. I'm working on a script where I need to map a SCSI LUN to a VM via RDM. I know the LUNs (201 and 202). I'm thinking that I need to use Get-ScsiLun, Get-ScsiLunPath, and New-HardDisk to get this done.

I tried this:

Get-ScsiLun -VmHost host.domain.com -LunType Disk | select *

but it doesn't return the LUN in the results.

I'm not sure how to go about this. Any ideas?

Reply
0 Kudos
13 Replies
Zsoldier
Expert
Expert

As long as the LUN's are mapped to the ESX hosts (not added as datastores) the following should work:

--------------  Example 2 --------------
C:\PS>$deviceName = ($host | Get-ScsiLun | Where {$_.CanonicalName -match "naa"})[0].ConsoleDeviceName
New-HardDisk -VM $vm -DiskType RawPhysical -DeviceName $deviceName
Obtains a valid device name for Raw Disk Mapping.  Then the command creates a RDM hard disk for the specified virtu
al machine, with the obtained device name.
Chris Nakagaki (中垣浩一)
Blog: https://tech.zsoldier.com
Twitter: @zsoldier
Reply
0 Kudos
Hypnotoad
Contributor
Contributor

Thanks for that. I saw that example in the help. My problem in that I need to look up the device name based on the LUN that I've assigned. The device name changes each day but the LUN is static.

Reply
0 Kudos
Zsoldier
Expert
Expert

That doesn't sound right.  The device name should be static once seen by your hosts.  It shouldn't be dynamically changing.

Chris Nakagaki (中垣浩一)
Blog: https://tech.zsoldier.com
Twitter: @zsoldier
Reply
0 Kudos
Hypnotoad
Contributor
Contributor

Let me explain. This script is for a DR site. We have two Compellent SANs. I replicate critical volumes to the DR SAN. My script connects to the DR SAN and maps the most recent replay (think snapshot) to my ESXi servers. When the replays change the device name also changes. The only thing that is static is the LUN numbers I used when creating the mapping.

I need a way to to lookup the device name based on the lun number input.

Reply
0 Kudos
Zsoldier
Expert
Expert

Ahh, that definitely throws a wrench into things.

Without knowing what data can be pulled from the Compellent SAN, makes things difficult for me to figure out.  If you haven't already, would suggest exploring the a sample LUN's extensiondata to find something that looks like it matches.  This is what I was doing:

$vmhost = Get-VMHost sampleesxhost

$LUNInfo = $vmhost | get-scsilun -LUNType disk

$LUNInfo | format-list * <-- find one you want to look up against

$LUNInfo[0] | format-list * <-- so you can see all properties available

$LUNInfo[0].extensiondata <-- I find one property under here curious that is called durablename.

Anyway good luck.

UUID might also be a good one to look up against.  Here is the vSphere API entry for scsilun to look up properties and how they are used.

http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.host.ScsiLun.html

Message was edited by: Zsoldier

Chris Nakagaki (中垣浩一)
Blog: https://tech.zsoldier.com
Twitter: @zsoldier
Reply
0 Kudos
avlieshout
VMware Employee
VMware Employee

The only thing that you can use to identify a LUN on your SAN is its serialnumber which is part of the UUID.

If your replica's SN changes, you are probably creating a new copy everytime. I dont have any Compellent experience though.

I would look into the san box if there's an option to update the existing copy or maybe use a replica if licenses permit.

Otherwise, the only reliable solution is scripting against your san box to retrieve the SN of a disk's copy.

Good luck.

Arnim van Lieshout Blogging: http://www.van-lieshout.com Twitter: http://www.twitter.com/avlieshout If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos
Hypnotoad
Contributor
Contributor

I'm fidling around. Here are some command and their results that I have been playing with. As you can see, I can see LUN numbers. I'm interested in LUN 201 and 202. I'm not sure why only 202 is listed. Sometimes only 201 is listed. I think is has to do with multi-path.

$esx = Get-VMHost -Name esxhostname | Get-View

$hba = $esx.Config.StorageDevice.ScsiTopology.Adapter

$hba

RESULT

Key             : key-vim.host.ScsiTopology.Interface-vmhba38
Adapter         : key-vim.host.BlockHba-vmhba38
Target          :
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Interface-vmhba39
Adapter         : key-vim.host.BlockHba-vmhba39
Target          :
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Interface-vmhba0
Adapter         : key-vim.host.BlockHba-vmhba0
Target          : {key-vim.host.ScsiTopology.Target-vmhba0:0:0}
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Interface-vmhba1
Adapter         : key-vim.host.BlockHba-vmhba1
Target          :
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Interface-vmhba2
Adapter         : key-vim.host.FibreChannelHba-vmhba2
Target          : {key-vim.host.ScsiTopology.Target-vmhba2:0:3, key-vim.host.ScsiTopology.Target-vmhba2:0:1}
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Interface-vmhba3
Adapter         : key-vim.host.FibreChannelHba-vmhba3
Target          : {key-vim.host.ScsiTopology.Target-vmhba3:0:2, key-vim.host.ScsiTopology.Target-vmhba3:0:1}
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Interface-vmhba33
Adapter         : key-vim.host.InternetScsiHba-vmhba33
Target          :
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Interface-vmhba34
Adapter         : key-vim.host.InternetScsiHba-vmhba34
Target          :
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Interface-vmhba35
Adapter         : key-vim.host.InternetScsiHba-vmhba35
Target          :
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Interface-vmhba36
Adapter         : key-vim.host.InternetScsiHba-vmhba36
Target          :
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Interface-vmhba37
Adapter         : key-vim.host.BlockHba-vmhba37
Target          :
DynamicType     :
DynamicProperty :

$target = $hba[4].Target

$target[0].Lun

RESULT

Key             : key-vim.host.ScsiTopology.Lun-02000500006000d3100011df000000000000000017436f6d70656c
Lun             : 5
ScsiLun         : key-vim.host.ScsiDisk-02000500006000d3100011df000000000000000017436f6d70656c
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Lun-02006500006000d3100011df0000000000000001ed436f6d70656c
Lun             : 101
ScsiLun         : key-vim.host.ScsiDisk-02006500006000d3100011df0000000000000001ed436f6d70656c
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Lun-0200ca00006000d3100011df000000000000000299436f6d70656c
Lun             : 202
ScsiLun         : key-vim.host.ScsiDisk-0200ca00006000d3100011df000000000000000299436f6d70656c
DynamicType     :
DynamicProperty :

$lun = $target[0].Lun

PS C:\> $lun[2].Lun
202
PS C:\>

Reply
0 Kudos
avlieshout
VMware Employee
VMware Employee

The 201 and 202 are just index numbers. You cannot rely on them.

Use the large hex number in de scsi property. That is the SN.

It looks like this is esx4.x right?

U should better use the get-esxcli cmdlet to talk to the storage api.

See also

http://www.van-lieshout.com/2011/01/esxcli-powercli/

Sent from my iPad

Arnim van Lieshout Blogging: http://www.van-lieshout.com Twitter: http://www.twitter.com/avlieshout If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos
Hypnotoad
Contributor
Contributor

201 and 202 are the LUN numbers that I'm assigning when I map the volumes to the ESXi hosts. These will not change unless I change them. This is a FC SAN if I wasn't clear.

All of my hosts are ESXi 4.1 Enterprise Plus.

Reply
0 Kudos
avlieshout
VMware Employee
VMware Employee

Nope. 201 and 202 are internal indexnumbers. I also have lun 201 and that's definitely not the same disk as yours.

You need to use the lun's uuid.

Arnim

Sent from my iPad

Arnim van Lieshout Blogging: http://www.van-lieshout.com Twitter: http://www.twitter.com/avlieshout If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos
Hypnotoad
Contributor
Contributor

I have LUNs 1, 5, 101, 102, 201, and 202 assigned at my SAN to two ESXi hosts. The Powershell commands return those same exact numbers. If these are not the same LUN numbers then that is one hell of a coincidence.

Reply
0 Kudos
avlieshout
VMware Employee
VMware Employee

OK, I must admit that I was wrong regarding the LUN numbers. I mixed them up with the Disk key that's assigned to a VM's harddisk.

Nevertheless, what I'm saying that you should use the SN number from the storage array that's part of the UUID of the LUN is still valid.

The SN is the only reliable property that is unique to a disk.

The LUN number is assigned from the storage array, but someone could assign another disk with the same number to another host.

Let me show you an example:

Key             : key-vim.host.ScsiTopology.Lun-02004900006005076801818092b00000000000116c323134352020
Lun             : 73
ScsiLun         : key-vim.host.ScsiDisk-02004900006005076801818092b00000000000116c323134352020
DynamicType     :
DynamicProperty :

Key             : key-vim.host.ScsiTopology.Lun-02003d00006005076801818092b00000000000116c323134352020
Lun             : 61
ScsiLun         : key-vim.host.ScsiDisk-02003d00006005076801818092b00000000000116c323134352020
DynamicType     :
DynamicProperty :

Both outputs show the same disk (SN ends with 116c), but from another host (Side Note: Both hosts aren't part of the same cluster, but see the same LUN). As you can see, the LUN numbers are different, but we are still looking at the same LUN.

Now I did poke around for you to do this by the LUN number.

The script below will do the trick:

$lunNumber = 201
$lunKey = ""
$vm = "myVM"
$VMHost = Get-VMHost "myHost"
foreach ($adapter in $VMHost.ExtensionData.Config.StorageDevice.ScsiTopology.Adapter) {
  foreach ($target in $adapter.Target ) {
    foreach ($lun in $Target.Lun) {
      if ($lun.lun -eq $lunNumber) {
        $lunKey = $lun.ScsiLun
      }
    }
  }
}
if ($lunKey) {
    $disk = $VMHost | Get-ScsiLun | Where {$_.Key -eq $lunKey}
    New-HardDisk -VM $vm -DiskType RawVirtual -DeviceName $disk.ConsoleDeviceName
}
else {Write-Warning "LUN $lunNumber not found!"}


Let me now if this is what you're looking for.

Cheers,

Arnim

Arnim van Lieshout Blogging: http://www.van-lieshout.com Twitter: http://www.twitter.com/avlieshout If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos
Hypnotoad
Contributor
Contributor

Thanks so much Arnim. That worked perfectly.

The reason I didn't want to use the serial number was because it would not be the same when running the script later. This script I'm building creates a new SAN volume that is based on a snapshot of a replicated volume. Since the volume is different each time I'm assuming that the serial numbers would also be different. The only values that I can control are the LUN numbers. The LUN numbers are assigned in the this same script so it shouldn't be a problem. It's possible that someone could hijack a LUN number in the future but since I'm the storage guy as well as the VMware guy the rist is low.

--Patrick

Reply
0 Kudos