Get-InventoryPlus – Inventory of all vSphere objects

Often I have to get a complete list of all the objects in a vSphere environment. From the PowerCLI cmdlets, the Get-Inventory cmdlets looks like the obvious candidate to tackle such a request. But the cmdlet seems to have some shortcomings. It definitely does not return all vSphere objects.

Hence I set out to write this Get-InventoryPlus function.

The function was demonstrated for the first time during the 24th VMUGBe in Mechelen.

The Issues

A quick demonstration of the problem. When you do a Get-Inventory, a list of vSphere objects is produced.

But some vSphere objects are definitely not in the list. To make this more visible, I grouped the returned objects by objecttype.

There are no network, nor storage related objects in the list returned by Get-Inventory !

With my Get-InventoryPlus function you do get a complete inventory. Notice how we now get network and storage related objects returned.

And there is in fact a 2nd issue !

Have a look at these two views of the entry named Folder2. Are we looking at one object or two objects ?

To take the suspense away, an object of the type Folder can in fact appear twice in your inventory, and they are not the same object ! These are the so-called “Yellow” and “Blue” folders. They can have the same name, and appear to be in the same location. But in fact they are not in the same location. It’s an optical illusion, that is caused by the hidden folders ! In this case the hidden folders named ‘host’ and ‘vm’

The view in old C# client makes this more visible.

So I had to make sure that the function could make the distinction between the two !

Annotations

Line 29: By default the function gets the inventory of the vSphere server that is in $Global:DefaultVIServer, but you can ask for the inventory of another vSphere server with this Server parameter. Notice the Type used for the Server parameter, it is the “portable” way of specifying a Type, as described in PowerCLI Best Practice: Correct Use of Strong Typing.

Line 36: Since the helper function can be called with different types of vSphere objects, the $Itemp parameter is defined as an object of the base ManagedEntity type. All derived Types will be accepted.

Line 42,46,58,63,102,113: Depending on the type of object, the path upwards needs to use different properties. That is where the UpdateViewData method comes in handy, to just add the required property.

Line 73: The function traverse the path bottom up, as a consequence the elements in the $path array needs to be reversed, before the path string can be created.

Line 89: The script uses an array to hold the names of all hidden folders

Line 135-138: if an object has a “yellow” and a “blue” path that are the same, the BluePath property is retained, and the Path property is set to the NoValue string

Line 139-141: a Template object, by definition only has a BluePath

Line 147-152: All vSphere information can be retrieved starting from the ServiceInstance object

Line 155: The ContainerView is the simplest method to find all vSphere objects

Sample Usage

The usage is rather straight-forward.

PowerShell

1

Get-InventoryPlus

Will produce something similar to this

A call of the Get-InventoryPlus function will produce a number of objects. Each object has sufficient properties to uniquely distinguish it in the vSphere environment.

I tested the function in my lab against many possible configurations, but it is always possible I missed a “special” case. If you should encounter such an issue, please let me know.