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.