Easy Livin'

The initial version 6 of PowerCLI, the Windows PowerShell interface for managing VMware vSphere, appeared in March 2015 to coincide with the release of vSphere 6.0. In mid-September 2015, release 2 followed. Because VMware has finalized some important PowerCLI 6 features in R3, we only look at the R3 version in this article. If you are still using PowerCLI R1 or R2, you might want to upgrade to R3 to take advantage of all the new features and to future-proof your scripts from the outset.

If your vSphere landscape is still based on version 5.5 or earlier, you can still use PowerCLI 6. Although some innovations are only relevant for vSphere 6, such as support for the new virtual machine hardware version 11 in conjunction with the New-VM or Set-VM cmdlets, the shell is nevertheless 100 percent downward compatible with all version 5 products. An update to PowerCLI 6 is also worthwhile in the context of a vSphere 5.x environment, for example, to benefit from the improved PowerCLI architecture. Scripts that explicitly address the new 6.0 features will not work in this case.

Modules Instead of Snap-Ins

The PowerCLI structure has undergone a rigorous adaptation to the PowerShell design specifications. Almost all the essential functions, for example, are now implemented as modules, and their paths are also properly registered in PowerShell ($env:PSModulePath). The only exceptions are AutoDeploy and ImageBuilder, whose cmdlets are still bundled in PowerShell snap-ins, as well as the core cmdlets of vSphere automation, which are always implicitly loaded whatever else you do.

The architectural changes mean that existing scripts that explicitly look for snap-ins may no longer find them, so you might want to adjust your scripts to search for PowerShell modules instead of snap-ins.

Fixed Bug in the Installer

R3 fixes an annoying bug in the installer of former PowerCLI versions, in which, without explicitly stating a path, modules were only visible to the user who originally installed PowerCLI. This bug is fixed now, which alone is a good reason to upgrade to R3. VMware also has unified the installer, with only a single download for all components. The user can now select or deselect three categories during installation: vSphere, vCloud, and Update Manager, which is also supported by a module in PowerCLI 6 R3.

Incidentally, the PowerShell interfaces for managing Horizon View and Mirage are no longer part of the PowerCLI distribution in version 6.0. Although the cmdlets largely follow the same object model, they are only available when you install View or Mirage.

Incidentally, the changes to reflect Microsoft's increasingly strict design guidelines are noticeable in the system requirements for PowerCLI 6; you need at least PowerShell 4.0 and .NET Framework 4.5 on your system.

PowerCLI as a Community Product

Releasing the first version of PowerCLI – at that time, still under the name VI Toolkit 1.0 with around 120 cmdlets – in July 2008 was a risky business, because PowerShell at the time was not nearly as powerful and enjoyed nothing like today's popularity among Windows administrators. Thanks to the established Perl-based RemoteCLI, thousands of scripts for managing the VMware infrastructure (VI), from which vSphere (version 4) later emerged, already existed.

PowerCLI was a complete success, primarily thanks to partners and customers, who adopted the new versions into their own scripting environments, tested them thoroughly, and contributed feedback. Part of this feedback is now institutionalized in the form of PowerCLI 6; for the first time, the shell asks the user on first launching the newly installed PowerCLI environment if they would like to participate in the Customer Experience Improvement Program (CEIP). If you select Join, PowerCLI attempts to transmit anonymized data on the use of cmdlets – and the issues that arise – to VMware. Of course, you can change your initial choices later with

>Set-PowerCLIConfiguration -ParticipateInCEIP <$set>

where substituting $true for <$set> indicates participation and $false indicates nonparticipation.

If the computer on which the user is working with PowerCLI Shell has Internet access, the Get-PowerCLICommunity command launches the default browser, pointing to the home page of the VMware PowerCLI community.

Renamed Cmdlets

VMware strictly adheres to the PowerShell guidelines in version 6, so three cmdlets had to be renamed because the verbs did not belong to the permitted scope by default. Thus, Shutdown-VMGuest became Stop-VMGuest, Apply-VMHostProfile became Invoke-VMHostProfile, and Apply-DrsRecommendation became Invoke-DrsRecommendation. However, the old cmdlet names still live on as aliases in the current release to ensure downward compatibility. Nevertheless, you should replace the old cmdlet names in existing scripts with the new names when you first encounter them. Unfortunately, VMware apparently overlooked the need to rename an Image Builder cmdlet, because Apply-ESXImageProfile still only listens for its non-standards-compliant name.

Guest Operations Unified

Manufacturers of development environments sometimes find it difficult to remove commands, or other objects that have become obsolete, permanently from the scope of their products. The main reason is that, ultimately, you never know which important scripts might still be using obsolete constructs. VMware has apparently chosen to make this move in the PowerCLI Core automation interface scope and marked five cmdlets as deprecated. This is true of all *-VMGuestNetworkInterface (Get and Set) and all *-VMGuestRoute cmdlets (New, Get, and Remove).

As of the next PowerCLI version what happens within a VM itself will be strictly controlled using the Invoke-VMScript cmdlet. Before you start mourning the network cmdlets, however, remember that VMware used the Invoke-VMScript code for these right from the outset. A look in the scripts subfolder of the PowerCLI installation directory reveals some scripts that enable a seamless transition to the "new" cmdlet for network configuration on Windows and Linux.

However, our recommendation for Windows VMs, instead of batch files, is the PowerShell cmdlets *-NetIPInterface, *-NetIPConfiguration, *-NetIPAddress, and *-Net-Route developed by Microsoft. The sixth command dropped by VMware is not as old as the guest cmdlets and comes from the vCloud collection: Instead of the Get-OrgNetwork cmdlet presented in January 2012, VMware now recommends consistent use of Get-OrgVdcNetwork. This is not a simple name change, because it also changes the parameter set, so scripts that use this cmdlet need to be investigated and adapted.

Under the Hood of the Host

VMware introduced the VMHostHardware object to allow insight into the ESXi host hardware. It provides information on the manufacturer, BIOS, power supplies, CPU, RAM, and network cards (but only their numbers). With the Get-VMHostHardware cmdlet, you can retrieve the object in question for the specified host. Using -WaitForAllData delays computing the resulting VMHostHardware object until all the required information has been collected. Without this parameter, the object will be returned faster, but the data you obtain might not be up to date.

To get more information about the built-in host PCI cards, VMware admins can use the new Get-VMHostPciDevice cmdlet. The results can be limited to the device class or name of the device.

PowerCLI and Storage

VMware recognized early on that storage is a key factor in the world of virtualization. Unfortunately, many of the innovations that make the VMware products unique in the field of storage connectivity have been slow to be adopted into PowerCLI or are simply missing. This deficit is resolved in version 6; PowerCLI now stands on an equal footing with other management tools.

One of the most important innovations relates to VSAN support and demonstrates the great community influence on PowerCLI, because the code base of the new commands comes from a Fling, an unofficial development by three VMware employees in February 2015 that was published on the VMware Labs website. In addition to the cmdlets required for managing the VSAN resources (*-VsanDisk and *-VsanDiskGroup), some core objects of the vSphere module needed to be updated. For example, Set-Cluster and New-Cluster have two new parameters: -VSANEnabled determines whether VSAN functionality exists in the corresponding cluster, and -VSANDiskClaimMode governs how the existing cluster disks are added to the VSAN. The permissible values are Automatic and Manual. Additionally, Set-VMHostNetworkAdapter and New-VMHostNetworkAdapter now have the new -VsanTrafficEnabled parameter. The properties described above have been added to the cluster object and HostNic object.

As you know, an NFS 4.1 data store in vSphere focuses more sharply on authentication compared with NFS 3, because the new NFS standard uses Kerberos v5 authentication, which can be handed over to the Set-DataStore cmdlet in the form of the -Kerberos parameter. The complete command is

>New-Datastore -Name <display name> -NFS -NFSHost <Name/IP of NAS> -Path <export path> -Kerberos

Cmdlets have also been added to manage the associated user login credentials for each ESXi host, including

>New-NFSUser -VMHost <ESXi-Host> -Username <Name> -Password <password>

or

>New-NFSUser -VMHost <ESXi-Host> -Credential <PSCredential object>
 
>Set-NFSUser -VMHost <ESXi-Host> -NFSUser <NFSUser object> -Password <new password>
>Get-NFSUser -VMHost <ESXi-Host>
 
>Remove-NFSUser -NFSUser <NFSUser object>

VMware introduced the vSphere API for Storage Awareness (VASA) with vCenter 5.0 back in August 2011 but has only now implemented it in PowerCLI. In addition to the VASAStorageArray and VASAProvider object classes, the cmdlets Get-VASAStorageArray (the output can be filtered by LUN, name, or VASAProvider), Get-VASAProvider and New-VASAProvider have been added.

In the latter case, it is possible to pass in a certificate explicitly for the new provider to be added (-Certificate) or tell vSphere to trust the existing certificate permanently (-Force). The required authentication can be passed in as a PSCredential object (-Credential) or explicitly (-UserName and -Password). Finally, there is now Remove-VASAProvider; note that all VASA providers are removed if the implicit -Provider parameter is not specified.

All Get cmdlets described here accept the additional -Refresh parameter, which reads the currently active VASA configuration of the host in question before computing the results. This process can take a while, depending on the complexity of the storage landscape. Without -Refresh, the configuration stored in vCenter is used.

Finally, VMware added four new cmdlets – Get-VAIOFilter, New-VAIOFilter, Set-VAIOFilter, and Remove-VAIOFilter – for its new VAIO storage API (vSphere API for I/O filtering) in PowerCLI 6. VAIO represents a further step toward the VMware software-defined data center.

DRS Up Close

Another new feature of PowerCLI 6 will primarily interest vSphere users who operate extensive DRS (distributed resource scheduler) infrastructures and need to diagnose the behavior of DRS from time to time. The new Get-DrmInfo cmdlet provides "DRM bundles" – a packed collection of DRS logs.

The cmdlet's parameters let you restrict the output to one or more clusters and – what is even more interesting – to a date and time interval, which helps make the search for the unwanted DRS recommendation and the factors that led to it far more efficient. The new cmdlet is the only export from the equally new VMware.VimAutomation.HA module.

Support for Operations Manager

VMware.VimAutomation.vROps is another new PowerCLI module that provides 12 cmdlets for scripting the vRealize Operations Manager. A session always begins with Connect OMServer and ends with Disconnect OMServer. If you only want to interrupt a session and resume it later on, you can read the Session Secret and then re-connect with it.

Within the session, you have access to a variety of monitoring information, such as recommendations, alarms, and their definitions; the resources managed by the Operations Manager; statistical data for the individual metrics; and more.

The only cmdlet that lets you influence the function of the Operations Manager directly is set-OMAlert, however. Currently it has four operations: TakeOwnership, ReleaseOwnership, SuspendMinutes, and Cancel.

Thus, the integration of Operations Manager with existing ITSM (IT Service Management) infrastructures and processes is now also possible with PowerShell. If you want to adjust the configuration of Operations Manager objects, you currently still need to resort to the GUI.

Conclusions

With PowerCLI version 6, VMware demonstrate strategic skill in the choice of technologies for managing its own products. The comprehensive object model, which had already been developed for web services, could be well represented in .NET and thus also in PowerShell. The update to the current version is worthwhile, even if some adjustments to existing scripts might be necessary.