The vSphere API is not just for programmers

The topic of the VMworld 2009 session which Luc Dekens and I gave recently was how to take PowerCLI to the next level. I’ll explain that premise for a bit in this post for those who may not have been able to make it to the session (or the show, for that matter).

PowerCLI has a lot of functionality built in. As of this writing, there are 165 cmdlets that let you do a wide range of tasks such as starting virtual machines or creating virtual switches. Cmdlets are great because they are high-level, task-based, and their usage is mostly consistent across all domains, whether you are talking about virtualization or managing your mail servers.

Here’s a PowerShell command which will display all of the various types of objects which you can manipulate with PowerCLI.

PS > Get-VICommand | sort noun | group noun | Format-Wide name

CDDrive Cluster

CustomField Datacenter

Datastore DrsRule

FloppyDrive Folder

HardDisk Inventory

Log LogType

NetworkAdapter OSCustomizationSpec

ResourcePool ScsiLun

ScsiLunPath Snapshot

Stat StatInterval

StatType Task

Template Tools

VICredentialStoreItem VIEvent

View VIObjectByVIView

VirtualPortGroup VirtualSwitch

VIServer VIToolkitConfiguration

VIToolkitVersion VM

VMGuest VMHost

VMHostAccount VMHostAdvancedConfiguration

VMHostDiagnosticPartition VMHostFirewallDefaultPolicy

VMHostFirewallException VMHostFirmware

VMHostModule VMHostNetwork

VMHostNetworkAdapter VMHostNtpServer

VMHostProfile VMHostProfileCompliance

VMHostService VMHostSnmp

VMHostStartPolicy VMHostStorage

VMHostSysLogServer VMResourceConfiguration

VMScript VMStartPolicy

Even so, the vSphere application programming interface (API) is so large that there are still an astonishing number of things which are not handled by the existing set of cmdlets. Sure, VMware continues to work on this toolkit and to expand its capabilities — the rumor is that over 200 cmdlets will ship with version 4.1 — but the team that works on PowerShell is limited by time and resources, so it’s doubtful that they’ll reach parity with the API anytime soon.

Luckily, there is a release valve — a hidden door, if you like, that will let you go behind the scenes to go where no VMware Infrastructure (oops, meant to say vSphere) admin has gone before. The name of that hidden door is the Get-View cmdlet. “Get” in the PowerShell world just means to retrieve an object from somewhere. But what is it really that you are getting? You are getting an unfiltered view of the “managed objects” which make up the heart of the API. Once you have that view, you can do anything you want which the underlying API supports.

Here is a quick example of the sort of cool things you can see with Get-View:

PS > $h = Get-VMHost | Get-View

PS > $h.Summary.Config.Product

Name : VMware ESX

FullName : VMware ESX 4.0.0 build-164009

Vendor : VMware, Inc.

Version : 4.0.0

Build : 164009

LocaleVersion : INTL

LocaleBuild : 000

OsType : vmnix-x86

ProductLineId : esx

ApiType : HostAgent

ApiVersion : 4.0

InstanceUuid :

LicenseProductName : VMware ESX Server

LicenseProductVersion : 4.0

DynamicType :

DynamicProperty :

And now you know how to write a script to make sure your host servers are all on the same patch level!