Runtime Name via Extensiondata and New-VIProperty

One of the demos we did in our VMworld 2010 US and Europe sessions, showed the use of the new Extensiondata property and of the new New-VIProperty cmdlet. Both features were introduced with PowerCLI 4.1. In my PowerCLI 4.1 brings the New-VIProperty cmdlet post I already showed the interesting possibilities this new cmdlet offers.

On my return from VMworld Europe there was a new thread in the PowerCLI Community that asked how one could get at the Runtime Name property as it is shown in the vSphere Client. The Get-ScsiLun and Get-ScsiLunPath cmdlets unfortunately do not return that property. So I guessed it was time to show once more the strength of the New-VIProperty cmdlet.

Intro

The basic problem with the Runtime Name is the fact that this name is not available as a single property.

The information to compose the name, on the other hand, is available. It’s just a matter of retrieving the correct data. Via the HostSystem object we can get to the HostStorageDeviceInfo object. Once we have this object, it’s a matter of following the correct pointers and to compose the Runtime Name.

The script

Annotations

Line 1: The function requires PowerCLI 4.1

Line 28-29: To make the retrieval easier, the script uses two hash tables to store the HBA Device Name.

Line 34-39: Populate both hash tables.

The script does nothing more than display the Runtime Names for one or more ESX(i) hosts.

The function was written to show that the Runtime Name can be composed from the information available in the HostStorageDeviceInfo object.

Adding the property

From the previous script we have a working method to compose the Runtime Name. The next step is to extend the output of the Get-ScsiLun cmdlet to return the property. That’s where the New-VIProperty cmdlet comes into play.

Annotations

Line 1: All PowerCLI objects are allowed with the New-VIProperty cmdlet.

Line 4: Via the VMHost property in the ScsiLunImpl object, the script has access to the complete HostSystem object. And from there it is straightforward to go to theย  HostStorageDeviceInfo object.

Line 5: Via the Key property the script finds the correct LUN.

We can now get at the Runtime Names with the Get-ScsiLun cmdlet.

Don’t you just love the New-VIProperty cmdlet ๐Ÿ™‚

11 Comments

    Roger

    Hi Luc,
    How can I get the RuntimeName, LunID and size for all Vmhba in the same output?

    Thanks

    Aman

    Hi LucD,
    Would this work with PCLI 5.
    I have this error –
    The script ‘runtimename.ps1’ cannot be run because the following snap-ins that are specified by the “#requires” statements of the script are missing: VMware.VimAutomation.Core (Version 4.1).
    At line:1 char:18
    + .\runtimename.ps1 <<<<

      LucD

      @Aman, yes it should be able to run with PowerCLI 5.x.
      Just remove the #requires line from the script

    Sean

    Hi Luc,

    I am using this for a deployment of older ESX 4.0 hosts and am trying to get a script together that will show each path to a datastore’s status. (i.e. active/dead paths) – there are a couple of scripts out there already, but they don’t seem accurate for me – they tend to duplicate info. Anyway, I found your post and am using this VIProperty to grab the Runtime names for each LUN. So each LUN that I retrieve using Get-ScsiLun ends up having 4 x Runtime’s listed in it’s .Runtime property due to each ScsiLun having 4 x paths – i.e. each datastore has 4 x paths to the ESX hosts – 2 on each HBA, going to different SAN SPs. I would like my script to report each path, its status (active/dead) as well as the Runtime name for each path – just like vCenter reports in the vSphere client – see my screenshot for illustration – https://dl.dropbox.com/u/450727/Temp/lunpaths.jpg – my problem is that each Lun I get with the Get-ScsiLun cmdlet, gets 4 x Runtime names, but I don’t know how to match up each to its respective path. Any pointers or advice? ๐Ÿ™‚ Here is an example of using your VIProperty to get the Runtime names and how I want to match them up to Paths – https://dl.dropbox.com/u/450727/Temp/lunpaths-example.jpg

    Cheers,
    Sean

      LucD

      @Sean, you can connect the LUN with the paths based on for example the CanonicalName.
      I can provide you some sample code but how do you want to show the information ?
      One line with the Runtimename and the Canonicalname followed by the 4 paths and their status ?
      And how do you want to see the paths ? The SAN target ?

    Avinash Shetty

    Hi Luc where can i get details sfor the .net properties for powershell ? like when you say ” “$scsilun.VMHost.ExtensionData.Config.StorageDevice ” how can i know what options do i have for each cmdlet ?

      LucD

      @Avinash, there are a few basic actions you can take to discover the properties that are available in an object.
      1) Use the Get-Member cmdlet to discover the properties that are present
      2) Use an editor with the option to view variables to investigate an object

      The Extensiondata property is a door to the server-side objects. These server-side objects are documented in the VMware vSphere API Reference Documentation.

      For example, take the HostSystem managed object. From there you can follow the path Config.StorageDevice and so on.

    John Middleton

    When I try running the ‘RunTimeName’ script it returns:

    WARNING: The specified script block may contain a reference to the ‘$_’ variable. If you want to reference the object being extended, please use ‘$args[0]’ instead.

    Is this a normal warning or what am I missing …?

    Thx, – John M.

      LucD

      Hi John, that is just a warning. In this case you can safely ignore it.
      Note that in the latest PowerCLI 4.1U1 build the Get-ScsiLun cmdlet returns the RunTimeName. There is no need anymore to use New-VIProperty if you’re on that build.

    John Middleton

    So are you basically saying that be adding the New-VIProperty we are in effect linking the RuntimeName to the ScsiLun command..?

    Does this need be done only once or each time the ScsiLun command is called?

    Am I correct in thinking that to verify HBA multipathing I could look at the Runtime Name and checks that the target ( T0 ) is incremented..?

    Thanks, – John M.

      LucD

      Hi John. Yes, the New-VIProperty cmdlet allows you to link new properties to an existing PowerCLI object. In this case I used the SCSILun object produced by the Get-ScsiLun cmdlet.
      You have to execute the New-VIProperty definition once and it will active for the duration of your session.
      An alternative is to store these New-VIProperty statements in one of your profile files, that way they are available in every session.
      I’m not sure if the Target number is a valid source of information to make conclusions concerning multi-pathing. It looks like it but I’m not sure if that is a valid conclusion.
      Perhaps a storage guru can give us a definitive reply.

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*

This site uses Akismet to reduce spam. Learn how your comment data is processed.