Why is the Get-ScsiLun RuntimeName field always empty in PowerCLI 6.0 and how do I get a LunID, now?

[MCioe]

I'm using PowerCLI 6.0 Release 2 and am testing my 5.5 scripts to make sure they still work ok with 6.0.

The more I look at this more I think it's an ESXi 6.0 problem - (ESXi 6.0 Update 1a)

I used a great script by Luc Dekens which tells you how to get a LunID using PowerCLI

The making of a New-VIProperty called lunID - LucD notes

This script is dependent on the RuntimeName field returned from the Get-ScsiLun cmdlet, which is now always blank in PowerCLI 6.0.

Is there another way to get the LunID?

I can see the LunID(s) when I VI Client into the host and look at the Storage adapters.

Basic steps:

$scsiList = get-vmHost -vm $vmName | get-scsiLun

$scsiList | select RuntimeName    

$scsiList | fl

RuntimeName always comes back blank, where it used to look like  vmhba0:C2:T0:L11

    where L11 is the LunID

Screenshot is enclosed.

Thanks,

Maureen

[CRad14]

Hmm, really odd

I am on PowerCLI 6 R1 and it is working fine for me....

Maybe just drop back to R1 and see if that helps.

[MKguy]

Does this really happen for all your LUNs? E.g. run Get-VMHost | Get-ScsiLun | Select CanonicalName, RuntimeName

Or could it be that the VM you're querying for there is hosted on NFS or VSAN or something?

I'm running the latest PowerCLI 6.0 R3 and don't have any problem accessing the RuntimeName, try updating to R3 as well:

https://my.vmware.com/group/vmware/get-download?downloadGroup=PCLI600R3

> Get-PowerCLIVersion

PowerCLI Version

----------------

   VMware vSphere PowerCLI 6.0 Release 3 build 3205540

---------------

Component Versions

---------------

   VMWare AutoDeploy PowerCLI Component 6.0 build 2358282

   VMWare ImageBuilder PowerCLI Component 6.0 build 2358282

   VMware vSphere PowerCLI Component 6.0 build 3205541

[MCioe]

I tried it with PowerCLI 6.0 R3 and PowerCLI 5.5. 

I have small lab environment, with just two ESXi hosts on an ISCSi network and one attached NetApp for storage. 

I am seeing the same behavior on a coworkers environment, too.  I'll have to look at ESXi, now...

[MCioe · Accepted solution]

This appears to be a bug on the ESXi side,  so I came up with an ugly workaround which is attached.

I used the get-scsiLunPath cmdlet which also has the LUN IDs built into the Name field. It returns a list of objects, but the LUN ID is always the same in each of  the LUNPath objects in my environment, so it works.

When the bug is fixed, the workaround will be skipped.

Overview:

     Get all the SCSI Luns for a given Server/Host

     If the RuntimeName field length is 0, do the workaround

           for each LUN retrieved from Server, call Get-SCSiLunPath | select -first 1; don't need the whole list

               Parse off the LUN ID from the end of the Name and convert to an int

                     do work:  compare found LUN ID to the one I'm looking for and save it.

[bobalob]

I made this into a function, including workaround.

Function Get-DataStoreName {
  Param (
    $SCSILunId = $(Throw "You must provide a SCSI LUN ID"),
    $VMHost = "ESXServer.example.com"
  )
  $SCSILuns = Get-ScsiLun -VmHost (Get-VMHost $VMHost)  
  $SCSILun = $SCSILuns | ? {$_.RuntimeName.split(":")[-1] -eq "L$($SCSILunId)" }
  #Awful workaround due to ESXi6.0 bug
  # See here https://developercenter.vmware.com/forums?id=2530#523885|3099553
  if (!($SCSILun)) {
    foreach ($SCSILunItem in $SCSILuns) {
      $ThisLunID = $SCSILunItem | Get-ScsiLunPath -ea 0 | Select -First 1 | % {$_.name.split(":")[-1] -eq "L$($SCSILunId)"}
      if ($ThisLunID -eq $SCSILunId) {
        $SCSILun = $SCSILunItem
        break;
      }
    }
  }

  $DSList = Get-Datastore |
  Where-Object {$_.ExtensionData.Info.GetType().Name -eq "VmfsDatastoreInfo"} |
  ForEach-Object {
    if ($_) {
      $Datastore = $_
      $Datastore.ExtensionData.Info.Vmfs.Extent |
      Select-Object -Property @{Name="Name";Expression={$Datastore.Name}},
        DiskName
    }
  }

  $DataStoreName = ($DSList | ? {$_.DiskName -eq $SCSILun.CanonicalName}).Name
  Return $DataStoreName
}