I was generating some VM reports using PowerCLI, so I was curious what the point of having 2 seemingly identical fields is.
for example:
$vm = Get-VM -Name 'test'
$vm.VMHostId
$vm.VMHost.Id
On a related note, is there an easy way to check the documentation for the meaning of any particular field?
I keep flipping between Online Documentation - Cmdlet Reference - VMware {code} for cmdlets and vSphere Web Services API - VMware API Explorer - VMware {code} for properties.
For example, vSphere Web Services API - VMware API Explorer - VMware {code} appears to be where "$vm.ExtensionData.Guest.Disk" and its properties "Capacity" and "FreeSpace" are documented, yet I can't find a similar page for "$vm.Guest.disks" and its properties "FreeSpaceGB" and "CapacityGB".
$vm.guest.disks.GetType() returns "DiskInfoImpl[]", which does not help me locate the relevant documentation page.
To take the suspense away, they are the same.
In other words, they are 2 different paths to get to the same. In this case, a PowerCLI .Net representation of a vSphere .Net object pointer (MoRef, see later).
The reason it is available in multiple locations, the PowerCLI Dev Team also deemed it useful (and it is) to have the full object representing an ESXi node available from a VirtualMachine object.
In PowerCLI there are 2 types of objects you need to know about.
These are objects that represent the objects vSphere works with internally.
They are documented in the vSphere Web Services API reference.
They contain all properties and methods that vSphere offers
These are objects that are created by the PowerCLI cmdlets.
They contain a selection of properties from the vSphere .Net objects
The selection is done by the PowerCLI Dev Team, and in such a way that they will offer most of what a regular vSphere admin/user will need.
These objects are documented in the PowerCLI cmdlet reference
In practice, what does this mean for the PowerCLI coder?
In most cases you will only need the PowerCLI .Net objects. They have most of the info you will need.
For more exotic properties and methods, you will have to go the vSphere .Net objects.
They offer you the full range of what is publicly available in vSphere.
The vSphere .Net objects can be reached in 2 ways.
In case you want to go from a vSphere .Net object to a PowerCLI .Net object, you can use the Get-ViObjectByViView cmdlet.
On a side note, in vSphere objects are linked to other objects through a so-called ManagedObjectReference (MoRef).
That is where the duality of the Get-View cmdlet comes in handy.
Besides allowing you to go from a PowerCLI .Net object to a vSphere object, it also allows you to follow these MoRefs. And that through the Id parameter.
This is in a nutshell, a very high-level overview of the objects available in PowerCLI.
Hope it helps
---------------------------------------------------------------------------------------------------------
Was it helpful? Let us know by completing this short survey here.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
To take the suspense away, they are the same.
In other words, they are 2 different paths to get to the same. In this case, a PowerCLI .Net representation of a vSphere .Net object pointer (MoRef, see later).
The reason it is available in multiple locations, the PowerCLI Dev Team also deemed it useful (and it is) to have the full object representing an ESXi node available from a VirtualMachine object.
In PowerCLI there are 2 types of objects you need to know about.
These are objects that represent the objects vSphere works with internally.
They are documented in the vSphere Web Services API reference.
They contain all properties and methods that vSphere offers
These are objects that are created by the PowerCLI cmdlets.
They contain a selection of properties from the vSphere .Net objects
The selection is done by the PowerCLI Dev Team, and in such a way that they will offer most of what a regular vSphere admin/user will need.
These objects are documented in the PowerCLI cmdlet reference
In practice, what does this mean for the PowerCLI coder?
In most cases you will only need the PowerCLI .Net objects. They have most of the info you will need.
For more exotic properties and methods, you will have to go the vSphere .Net objects.
They offer you the full range of what is publicly available in vSphere.
The vSphere .Net objects can be reached in 2 ways.
In case you want to go from a vSphere .Net object to a PowerCLI .Net object, you can use the Get-ViObjectByViView cmdlet.
On a side note, in vSphere objects are linked to other objects through a so-called ManagedObjectReference (MoRef).
That is where the duality of the Get-View cmdlet comes in handy.
Besides allowing you to go from a PowerCLI .Net object to a vSphere object, it also allows you to follow these MoRefs. And that through the Id parameter.
This is in a nutshell, a very high-level overview of the objects available in PowerCLI.
Hope it helps
---------------------------------------------------------------------------------------------------------
Was it helpful? Let us know by completing this short survey here.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Thanks for your earlier reply, I appreciated the detailed explanation!
So to confirm, this particular documentation page Online Documentation - Cmdlet Reference - VMware {code} shows FreeSpaceGB for example, but the "notes" field is empty. I'm aware there's a related .Net property "FreeSpace" which does have its own documentation describing the value, but is the meaning of FreeSpaceGB itself not documented anywhere?
I can basically guess it means the same as "FreeSpace", but I'm surprised the notes field doesn't go into any detail. I've noticed the same with most of the PowerCLI documentation, the property meanings aren't really documented compared to the .Net documentation (unless I'm missing something).
No, you are correct.
The PowerCLI documentation, more specifically the Types section, is far from complete.
And yes, most properties can be derived from the corresponding properties in the vSphere API Reference.
I'm hoping that one of the PowerCLI Ideas, namely Open source the PowerCLI Documentation (including the Help pages), will get implemented one of these days.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference