Summary: Two new features in VMware’s PowerCL make it easy for Windows PowerShell to gather virtualization configuration information.

Microsoft Scripting Guy, Ed Wilson, is here. Today we have a guest blog written by Josh Atwell.

. Take it away Josh…

Hi.  I’m Josh Atwell and I’m a SystemsAdministrator focused on scripting and automation in large virtualenvironments.  I am huge lover of Windows PowerShell, VMware’s PowerCLI, and all the fun ways they allow me to do more with less.  You can regularly find me blogging or tweeting about Powershell and PowerCLI.

Blog:  http://www.vtesseract.com

Twitter: https://twitter.com/Josh_Atwell

 

New to PowerCLI? I have a post specifically for those interested in getting started with PowerCLI.  I update it
whenever new items come to my attention so I hope you find it useful!

http://www.vtesseract.com/post/10685628144/resources-for-getting-started-with-powercli-automation

When I was approached by the Scripting Guys to guest blog this holiday season, I JUMPED at the opportunity. My exclamations scared the cat and led to a funny look from the Mrs. Why so excited? Because I was being given an opportunity to share with more people my favorite use of Windows PowerShell: VMware’s PowerCLI snap-in.

Using the VMware PowerCLI snap-in

The growing use of datacenter virtualization in organizations means more servers, more configurations, and more reporting for administrators to manage. Fortunately for all of us, Microsoft and VMware have worked hard to increase Windows PowerShell functionality in these environments. I would say they’ve done an amazing job; but unfortunately, gathering information in large environments can be very time consuming, even with Windows PowerShell. I’d like to share two of the best additions to VMware’s PowerCLI and how to use them to get information from the SDK quickly and efficiently. The two additions are ExtensionData and New-VIProperty. 

Using the Get-View cmdlet

Gathering information with PowerCLI is generally straightforward, but there are times where the cmdlets don’t provide all of the information about an object that you may need. VMware addressed this problem with the Get-View cmdlet. The Get-View cmdlet allows you to retrieve .NET view objects based on the criteria that you provide for the object type and based on filters. With some practice, you can use Get-View to retrieve data from the VMware SDK very quickly. These calls are essentially raw data grabs, and they lack the Windows PowerShell processing provided by traditional cmdlets like Get-VM.

Let’s give it a shot and search for information about my virtual machine “w2k8-std-32-2”. We already know the Virtual Hardware version of the virtual machine can be grabbed quickly through vCenter Server; but for demonstration purposes, let’s assume that it has to be grabbed as part of a Windows PowerShell script. I’m hoping it’s on Virtual Hardware version 7 because I need to take advantage of some specific features for that hardware version. Note that in the code shown here, the Filter parameter requires a hash table for the input. 

Get-View -ViewType VirtualMachine -Filter @{“Name” = “w2k8-std-32-2”}

This initial call returns and is significantly different than what is provided by a simple Get-VM call. This is shown in the image that follows.

 

At first glance, the information here is pretty cryptic, but notice that you now have visibility into a variety of different properties such as the virtual machine’s Config information. We’ll set our Get-View call to a variable and dig into Config to see what we can find there. I use the code shown here to examine the Config property.

$vmview = Get-View -ViewType VirtualMachine -Filter @{“Name” = “w2k8-std-32-2”}

$vmview.Config

The command and output associated with that command are shown in the following image.

I have condensed the information provided because it is quite extensive, but you can see right away that Version = vmx-07! Fantastic! Although it’s not as simply put as in vCenter server, it wasn’t too difficult. Using Get-View made it a very quick call and return.

Get-View calls can start to get quite complex and difficult if you are not familiar with the VMware SDK. VMware addressed this in a big way with their 4.1 release of PowerCLI. 

Introducing ExtensionData!

Taking a look into the virtual machine object, you see a new property called ExtensionData. ExtensionData was released with PowerCLI 4.1, and it provided Windows PowerShell folks a new and easier mechanism for getting into the vCenter SDK. Did I mention that it’s easy to use? It’s SUPER easy to use! In the image that follows, I use the Get-View cmdlet and pipe the output to the Get-Member cmdlet to display the ExtensionData property.

Let’s look at using ExtensionData to find the Virtual Hardware version that we just found with Get-View. We’ll begin by grabbing the VirtualMachine object for the virtual machine. You may ask why we would want to use Get-VM at all when we could simply use Get-View. That is an excellent question, and it is often discussed, but slightly beyond the scope of this post.

Back to work…

In the code that follows, I illustrate using the Get-VM cmdlet to retrieve the Config property from the object stored in the ExtensionData property. 

$vm = Get-VM “w2k8-std-32-2”

$vm.ExtensionData.Config

The image that is shown here displays the information that is contained in the Config property.

Well, that was easy enough, and now you have direct access to that info and more. The information provided with ExtensionData is exactly the same as what is provided with the Get-View command. However, we now have considerable flexibility for when and where we decide to grab this data.

We can take this one step further and generate a quick one-liner to report on the Virtual Hardware version for all virtual machines in my little lab setup. In the code that follows, notice that we use ExtensionData right in line without skipping a beat. 

Get-VM | Select Name,@{Name=”HardwareVersion”;Expression={$_.ExtensionData.Config.Version}}

 The command and data returned by that command are shown here.

 

Step it Up with New-VIProperty

PowerCLI also provides one more little feature that was introduced in version 4.1 that makes a report like this even easier in larger scripts. Because we know the hardware type is part of the virtual machine, let’s make it a direct property of the object with New-VIProperty! Here we’re using a value from the ExtensionData property for that VirtualMachine object. This will allow us to simplify our query. The simplified query is shown here. 

New-VIProperty -Name HardwareVersion -ObjectType VirtualMachine -ValueFromExtensionProperty ‘Config.Version’

Get-VM | Select Name, HardwareVersion

The command and the output associated by the command are shown here.

 

Keep in mind that this new property for the VirtualMachine object is only available while the session is active. If you plan to add new properties by using New-VIProperty, make sure that you include their creation in your scripts. If you don’t, you may be left wondering why you don’t have any data for that property. Doh! This lack of data is shown in the image that follows.

 

This was a simple example of these very PowerShell-ful features from VMware’s PowerCLI. I definitely recommend taking some time to explore with Get-View and the ExtensionData property in your environment. You’ll find a wealth of information about many objects in the inventory, including VMhosts, virtual machines, resource pools, folders, and more. When you find those valuable tidbits, you can speed up and simplify your scripts even more with the New-ViProperty cmdlet. That’s all for now! Good luck and good scripting!

~Josh

Thank you, Josh, for taking the time to share your knowledge with us. Join us tomorrow when I will talk about customizing the Windows PowerShell console. It is a cool blog that you will not want to miss.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy