So continuing on, let’s use the MOB to find a portgroup, and see if that helps us to know what we need to do. The MOB displays the internal object names for things rather than the display name you see in the VI client (the display name is still in there, but it’s usually a property of an object rather than the name of the object itself). If it makes navigation easier, open up the VI Client as well so you can see what internal object names map to which display names. To access the MOB:
1. Browse to https://vchostname/mob
2. Authenticate with whatever credentials you would use for vCenter
You are now for all intents and purposes at the landing page of where 'connect-viserver' takes you.
Click on the "Content" link in the value field of the content property. You can now see the top level of all the available managed objects of the vCenter box you connected to.
We know that networking is configured at the host level, so we need to find a host. The rootFolder property is the start of the inventory, let’s go there.
We are now effectively at the top level "Hosts & Clusters" folder in the VI Client Hosts and Clusters inventory view. As you can see here, in my case there is only 1 Datacenter defined, with an internal object name of 'datacenter-2'. Let’s see what’s in there.
OK, so by looking at the 'name' property, we can see that indeed we are looking at a Datacenter object (name removed to protect the innocent). Pretty easy to guess where we might find hosts... in the hostFolder object! Click through...
Because we have clusters defined in this Datacenter (in this case 2 clusters, 'domain-c28' and 'domain-c297' - again, internal object names), we are now actually looking at the cluster container. Clicking into one of the cluster objects will give us our host list.
OK, here's some useful info. We can see up the top of the screen that we are looking at a "Managed Object" Type. In the VI API there are Managed Objects (higher level objects), Data Objects (lower level objects), and then the data primitives like strings and integers. To illustrate, in this screen the host property contains an array of Managed Objects, the configurationEx property contains a single value that is a Data Object, and the name property contains a single value that is a data primitive. We can also see that the name of this Managed Object Type is ManagedObjectReference:ClusterComputeResource - logical for a cluster. Looking at the properties, we see one named 'host', which is also a Managed Object Type and named 'HostSystem'. Listed in the value field are our 2 host objects. Clicking on one of them, we come to the top level of a HostSystem Managed Object.
Cast your mind back to Volume 1, where I said that 'Get-View' was the window to the underlying objects of the VI API. Now that you know there are 2 different types of objects in the VI API, Managed Objects and Data Objects, I can be more specific and say that Get-View only returns _Managed_ objects. We used Get-View to get a Managed Object (hence why it's common to see variables of this nature have 'mor' or 'moref' in the name) to an ESX host. In order to do so, we had to pass the Get-View cmdlet the Id property of the object returned from Get-VMHost. The reason we had to use the Id property is just the way that the VI Toolkit team designed the Get-View cmdlet to work at this particular level.
$esxMoRef = Get-VMHost esxbox.corp.com | % {Get-View $_.Id}What Managed Object Type did we get a reference to? The exact one we are looking at now - a ManagedObjectReference:HostSystem. And to prove I'm not lying, try this for yourself. Create an $esxHostMoRef variable by issuing the command above in your own environment, and then type $esxHostMoRef.overallStatus and hit enter - it will return whatever value is in the overallStatus row of the webpage in front of you.
And that's where we'll leave it for this installment, Padawans (cue Yoda laugh). In Volume 3 we'll start to disect the script from Volume 1, and follow the rabbit hole a bit deeper.
No comments:
Post a Comment