I’ve had several people ask to understand more about Get-View. I will be doing several blog posts on this topic to hopefully help educate on what Get-View is and why it’s useful.
- Part 1: Introduction
- Part 2: Extension Data
- Part 3: Performance Impact
***Note: Get-view is a more advanced feature of PowerCLI. Administrators are able to fully utilize the benefits of PowerCLI without needing to learn Get-View. However, Get-view opens the door for even more flexibility and power in controlling your virtual environment.
Before dealing with Get-View, we need to understand a little bit about how PowerCLI works. The cmdlets like Get-VM will return nicely formatted information about a Virtual Machine, however, when Get-VM is run, there are a number of queries and formatting that takes place in the back-end that result in what is returned.
What happens when we return this same list using Get-View?
As you can see, a lot more information is returned. If this is the first time you are seeing this output, it can feel a little overwhelming and you will most likely want to just return to using Get-VM. But before you run off, let’s take a deeper look at this and try to understand what we are seeing.
To make this easier to sort through for this first time, let’s run the get-view cmdlet again but this time we’ll filter it for a single VM.
The –Filter parameter requires a hashtable for input, otherwise you’ll receive an error like this:
So we’ll run it the correct way and we’ll search based on the VM’s name.
get-view –viewtype VirtualMachine –filter @{“Name”=”SDDC-VCAC-IAAS”}
Ok, that’s not looking so bad now is it? ok, well you may still be saying “I don’t understand what I’m seeing….” but we have narrowed down the number of lines returned by looking at a single Virtual Machine.
What are we seeing?
What we see when running Get-View is the view object (Do not confuse ‘view object’ with ‘VIobject’ we’ll discuss this later). We can then dig into the different properties for this object and find large sums of information that may be useful for your needs.
We’ll first save our query as a variable:
$VM = get-view –viewtype VirtualMachine –filter @{“Name”=”SDDC-VCAC-IAAS”}
Now by typing the variable name ‘$VM’ we can see and work with the object.
It may take some practice and some time to get to know what all can be found within the view of each object… Don’t despair, it’s well worth it! let’s look in the Config property (VirtualMachineConfigInfo).
$VM.config
Here we can see some interesting information. We can see the VM Name, the Guest full name (Server 2008r2 64-bit), Hardware version, UUID, if it’s a template, and so on. These could be very useful when querying your infrastructure for reporting purposes especially (More to come in another blog post).
If we jump into the Summary section we see a number of other sections we can dive into. We’ll start with Runtime.
$VM.Summary.Runtime
We can see the VM is connected, powered off, VMTools installer is not mounted, etc.
On to Guest:
$VM.Summary.Guest
We can see here that VMTools is not running, the version is current, hostname, and IP would be here if the VM were powered on. For those of you who may want to write a script that sees if a VM is up and running before continuing, using the ToolsStatus property in a loop is an excellent way to judge if the script should proceed or loop again (*note: just because tools are running doesn’t mean the OS is always ready. sometimes it is good to place a start-sleep in the script once VMTools shows it is running, to ensure that the OS is fully up and running before continuing).
Finally, We’ll look at the Summary Config (do not get confused with the $VM.Config we looked at earlier):
$VM.Summary.Config
Here we see the amount of RAM allocated to the VM, the actual path to the VMX (in this case it’s [Datastore] Folder/VMName.vmx), # of CPU, NICs, Disks, and more.
In just a few queries we’ve been able to see a lot of data…
In the next article we will discuss how to use the data we find. and an even easier way of accessing this data for consumption.
Stay Tuned!
