On parents and nested properties

In a recent post on the vSphere PowerCLI Blog, called New Nested Properties for Navigating to Parent Objects in PowerCLI 4.1, some new features were introduced.

In PowerCLI 4.1 some objects now have, besides the ParentId property, the actual parent object itself. This will take quite some complexity out of several scripts. This is definitely a good improvement.

The 2nd novelty in that post were nested properties. Some SDK object properties are now mapped directly in the PowerCLI object. For example the VMHost object now holds the StorageInfo and NetworkInfo properties besides some others. And what is even better, there is hardly any performance impact since the values will only be loaded the first time you access the properties (similar to the ExtensionData property).

The selection of the SDK properties that are available this way were made by the PowerCLI Dev Team and are probably based on the most commonly used SDK object properties. But what if you want another property of the SDK object in your script ?

You can of course access all the properties of the SDK object through the ExtensionData property. But that comes with a performance penalty and will be visible when you run your script against a  larger vSphere environment.

Luckily PowerCLI 4.1 also introduced the New-VIProperty cmdlet.

With that cmdlet it’s quite simple to map your selection of SDK object properties into the PowerCLI object.

Suppose you want to see/check the ESX(i) host’s hardware in a script. Then you can just add this line

And bingo, each object returned by Get-VMHost will now have a Hardware property.

Another example is the yellow folder to which a VirtualMachine belongs. In the PowerCLI object for a VirtualMachine you have a Folder property, but that points to the blue folder in which a guest is located.

Again the New-VIProperty comes to the rescue.

Heck, you can even use a recursive function. Like this:

Don’t know how you feel, but I’m convinced of the power of the New-VIProperty cmdlet 🙂

Some personal reflections

With the power of the New-VIProperty cmdlet I feel that these extra properties, that PowerCLI 4.1 introduces, should have been optional or even left out by default. I know there is hardly any performance impact involved, but on the other hand they don’t make it easier for a PowerCLI newbie to grasp what is there.

What do you think ?

3 Comments

    FillDeeUK

    Hi Luc,
    Just a quick addition to the NumberOfVMs new-viProperty from Carter.
    I fine it usuful to know how many MV’s are powered on on each host, so I added the powered on count as shown below.
    It gives the warning about the $_ parameter, but works well enough for me

    New-VIProperty -ObjectType VMHost -name NumberOfPoweredOnVMs -Value { ($args[0] | Get-VM | ?{$_.PowerState -eq “PoweredOn”} | Measure-Object).Count } -Force

    Now a quick one liner tells me the state of my cluster without needing to load the VIC .

      LucD

      @FillDeeUK, great addition.
      I have added it to the VIProperties page.

Leave a Reply

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

*
*

ten + twenty =

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