Scripting: VMware PowerCLI vs. Microsoft PowerShell

It may seem unlikely to compare VMware PowerCLI and Microsoft PowerShell, because the former requires the latter to be installed first and is merely a vendor-specific addition to the core PowerShell environment.

It's also unlikely that someone would pick a virtualization platform merely based on its scripting capabilities. So rather than setting up a grudge match pitting one company against another, I will tell you what I like and dislike about each implementation. Hopefully, I can explain how both companies can improve their respective scripting offerings. Let's start with Microsoft.

Microsoft PowerShell
One aspect of virtualization management I like about Microsoft SCVMM is its built-in View Script window. This acts like a script recorder that gives you the ability to capture administrative actions as PowerShell scripts. A good example of this is when you are carrying out a migration task within SCVMM in order to move a VM to another Hyper-V host. At the end of the wizard a "View Script" button will display, showing the exact PowerShell commands needed in a script.

Figure 1 (click to enlarge)

In part, this is simply a happy fortune that comes from the way SCVMM was developed. Initially, SCVMM was designed to be managed by PowerShell, and then later a graphic management shell was developed around it so Windows admins didn't need to learn the PowerShell behind it.

It isn't difficult for Microsoft to expose the underlying PowerShell executing in the background. This won't help admins write PowerShell scripts with variables for each loop, error checking and logging, but it is very useful to folks who are new to PowerShell and at least gets them over the hump of learning how to carry out common administration tasks with the basic PowerShell cmdlets.

Today, Hyper-V doesn't have an official set of cmdlets, but a set was built by James O'Neill and is stored on Codeplex website. O'Neill took the APIs and wrote his cmdlets based on this. With the release of SCVMM 2012, the number of cmdlets is going to increase significantly, as the amount of tasks one can do in SCVMM in general is increasing substantially.

VMwarePowerCLI
VMware has made great strides with a number of new features to PowerShell, which it calls PowerCLI. In successive releases the company has significantly upped the number of cmdlets in the product to nearly 250. Earlier additions lacked cmdlets to control the ESX host iSCSI stack although the recent vSphere4.1 release has plugged that gap.

There are still the odd holes here and there. For instance, there aren't any meaningful cmdlets around VMware's Distributed vSwitches. Although its fair to say that PowerCLI 4.1 did update cmdlets which allow the administrator report information about an existing DvSwitch configuration including enhancements to the following cmdlets:
 

Get-VirtualSwitch
Get-VMHost
Get-VM
Get-VMHostNetworkAdapter
New-NetworkAdapter, Set-NetworkAdapter 

It appears the company favors its "Host Profiles" feature as the main configuration tool for newly created ESX hosts. Customers who buy the Enterprise and SKU qualify for both Distributed vSwitches and Host Profiles.

There are new deployment methods coming in future releases which emphasize the use of host profiles over PowerCLI for deployment of new ESX hosts. It's worth mentioning that vExpert Luc Dekens has developed his own functions that allow for management of DvSwitches. With that said, the primary use of PowerCLI in the VMware Community is reporting and checking the vSphere environment. Scripts such as virtu-al.net "Health Check" also have been extremely popular.

For everything else there is the VMware SDK. This extremely rich interface allows access to practically every action one may want to carry out, both at the host and the vCenter management server. This is in contrast to Microsoft where the only officially supported cmdlets are to SCVMM. There is some similarity between VMware and Microsoft there: both offer very limited PowerShell support for the so-called "free" editions of their hypervisors. Both companies are wary that customers could get a hypervisor for free, and manage it with command-line tools rather than paying a premium for the management piece.

The vCenter itself lacks the integration of PowerCLI directly in the vSphere Client. In searching for some way of "recording" administration as PowerCLI code, one could look at VMware Onyx, which is a free appliance that sits between the vSphere Client and vCenter and outputs the actions as raw PowerCLI SDK code. As a side note, it also outputs actions in a JavaScript format suitable for VMware's Orchestrator, a technology sadly underused by most VMware admins.

The output from Onyx a might be a bit overwhelming but don' be intimidated. There are more friendly ways of carrying out administration tasks via a GUI, as well as collecting the PowerCLI code after the task is completed. One should play around with the PowerGUI front end and its various PowerPacks that extend its functionality. PowerGUI works with a vast array of administration tasks including Active Directory, but from a virtualization perspective there are PowerPacks for VMware vSphere, Citrix XenServer, Microsoft HyperV, Virtual Disk Analysis, HP Virtual Connect and Quest vWorkspace.

Figure 2 (click to enlarge)


 

In the meantime, VMware is attempting to extend PowerCLI support to its other technologies, which is something that Microsoft is already down the road on. There is a PowerCLI for VMware virtual desktop solution, called View, but the implementation is very different from that of vSphere PowerCLI. It has a feeling more akin to a DOS command-line system than PowerShell and allows for pipelining and querying objects for their properties and attributes. As of now technologies like VMware Site Recovery Manager do not have PowerCLI, but it is likely on VMware's radar screen.

For the benefit of those folks not living in the Windows world, PowerShell and PowerCLI have sent shockwaves through the system administration world. But there are Linux-based scripters who may feel left out in the cold. VMware offers Perl and Microsoft does not, but that is to be expected.

These other toolkits aren't gaining much traction in the communities I travel in. Similar older CLI and remote CLI seem to be withering too such as VMware's port of its "ESX" commands to the vCLI and vCLI appliance. Right now they feel like an intermediary step intended to wean VMware customers off their dependency on the old "Service Console" environment. Right now it feels like PowerShell and PowerCLI will rule the sysadmin's roost for the foreseeable future.

You can follow SearchWindowsServer.com on Twitter @WindowsTT.

ABOUT THE AUTHOR
Mike Laverick (VCP) has been involved with the VMware community since 2003. Laverick is a VMware forum moderator and member of the London VMware User Group Steering Committee. Laverick is the owner and author of the virtualization website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users, and has recently joined SearchVMware.com as an Editor at Large. In 2009, Laverick received the VMware vExpert award and helped found the Irish and Scottish VMware user groups. Laverick has had books published on VMware Virtual Infrastructure 3, VMware vSphere4 and VMware Site Recovery Manager.