This week VMware released a new version of PowerCLI and this release is the most advanced version ever made. As the Product Manager for PowerCLI I am particularly proud of this release as we not only add core functionality to the vSphere cmdlets allowing access to report, manage and automate even more of the core infrastructure but yet again we introduce a number of new features allowing PowerCLI to reach even further into the SDDC and automate and integrate more products.
I always like to ask people what they want to see from PowerCLI next and for a long time now people have been talking to me about vROPs and telling me their use cases of being able to use the rich dataset and analytics provided by vROPs to make decisions and take further action with PowerCLI, something as simple as monitoring a web server to know when it is under duress and provision many more based on these statics all the way to being able to take action on storage systems by monitoring the workload over time. The use cases are endless and now achievable by the latest version of PowerCLI. More on this to come in a future post but lets just say I am excited to see what the awesome PowerCLI community does here.
There is so much to talk about in this release, I wanted to give you an overview in this post and then dive deeper into some of the key features in the future.
More Module Enhancements
The community made it clear that we had to move to modules, and whilst we are still getting there, in this release we made even more module enhancements, both to the core distribution model of PowerCLI cmdlets and also converting more of our code base from snapins to modules. In this version the License snap-in has been converted to a PowerShell module. In the new release the PowerCLI Modules have also been moved to the System PSModulePath allowing all users of a machine to access them once installed.
As briefly mentioned above, a new module and cmdlets have been added to this release to allow access to vRealize Operations, access to the entire public API is available from the $global:DefaultOMServers variable using the ExtensionData property and full cmdlets have been included for the most used features, this gives us a good mix of fully functional easy to use cmdlets and yet the access for advanced users to be able to access the entire API through the ExtensionData property to create their own functions to expose anything to automate vROPs. The following cmdlets were added for using with vROPs:
- Connection: Connect-OMServer , Disconnect-OMServer
- Alerts: Get-OMAlert, Get-OMAlertDefinition, Get-OMAlertSubType, Get-OMAlertType, Set-OMAlert
- Recommendations: Get-OMRecommendation
- Resources: Get-OMResource
- Statistics: Get-OMStat, Get-OMStatKey
- User Management: Get-OMUser
PowerCLI for Update Manager has always been available as a separate downloadable installer but it was hard to work with, you needed to work out which version of Update Manager you had installed on the server and install the exact version of PowerCLI cmdlets to work with it, this was obviously a pain when using multiple versions of vCenter or when trying to manage them from one machine. In this version PowerCLI for vSphere Update Manager is no longer a separate downloadable component or installer and is now included in the core PowerCLI installer, it is selected by default during the PowerCLI install wizard which allows for simpler and quicker deployment and management of VMware products through PowerCLI. Enhancements have also been made to ensure a better backwards compatibility experience of this module and now supports versions of vSphere Update Manager all they back to 5.5.
In the previous release we introduced PowerCLI for vCloud Air, allowing you to connect to your dedicated resources you have purchased and transfer your automation skillset into the cloud. In this release you can now also connect to and manage vCloud Air On-Demand (vCA) instances with the –VCA parameter added to the Connect-PIServer and the new Get-PIComputeInstance cmdlet to list all available compute instances. Existing cmdlets for managing vCloud Director and vCloud Air can be used to work with vCloud Air On-Demand where applicable. Additional to these enhancements a new cmdlet has been added to make it easier and enhance the ability to work with OrgVDC Networks called Get-OrgVdcNetwork.
ESXi Host Hardware
This feature was asked for in the PowerCLI Communities, this is just one of the places we monitor to work out what our future releases look like. New cmdlets have been added to work with ESXi host hardware, these cmdlets give the ability to interrogate your ESXi hosts and provide core system and hardware information.
Two new cmdlets have been added to work with this area:
- Get-VMHostHardware lists host information
- Get-VMHostPCIDevice lists all PCI Devices
Over the last number of releases we keep making enhancements to the storage cmdlets, with VSAN, IO Filters and now a number of enhancements have been made to the storage module introducing new cmdlets for working with VMware vSphere® API for Storage Awareness (VASA), NFS 4.1 and updated vSphere API for IO Filtering (VAIO) cmdlets.
The following new additional cmdlets are now available:
- New VASA Cmdlets : New-VasaProvider, Remove-VasaProvider, Get-VasaProvider and Get-VasaStorageArray
- New NFS Cmdlets: New-NfsUser, Remove-NfsUser, Get-NfsUser and Set-NfsUser
- Added VAIO filters Cmdlet: Set-VAIOFilter
A pet peeve of mine and others
In previous versions of PowerCLI when you started the interactive shell it would always start PowerCLI in the directory where we installed the components, as I watched people use PowerCLI I would see them run a CD\ to get back to the root of the C: or they would use it from the install directory and often their commands would line wrap making it slightly harder to read, a small but hugely beneficial change was made in this release, the PowerCLI starting directory has now been changed from the full install path of PowerCLI to the root of the installation drive.
Business as usual
As usual updates have been made for PowerCLI to support the latest versions of the software it works with, in this case Site Recovery Manager (SRM) was updated to 6.1 and additional functionality has been added to discover SRM servers when they are deployed in a “shared recovery model” and support has been added for the vCloud Director 8.0 features which are provided by the backwards compatibility agreement of the VCD API. All this and many more bug fixes and speed enhancements.