All the install instructions for the latest VMware PowerCLI say to use the Install-Module cmdlet. Unfortunately, on stock 2012R2, this cmdlet does not exist. Therefore, getting to the latest PowerCLI is nearly impossible. There are, however, several solutions.
In effect, Windows 2012 R2 is missing a component to make this a nonissue. That component is PackageManagement PowerShell Modules Preview, which came out in 2016. I presume that if I were using Windows 2016 or Windows 10, it might be a nonissue. I have not tested this. So, it is possible to download PackageManagement PowerShell Modules Preview for Windows 2012 R2.
Once you have the PackageManagement PowerShell Modules installed, you can follow Kyle Ruddy’s post on VMware Blogs. The key part I was missing was the Import-Module cmdlet call, which you have to create every time. So, re-creating the desktop shortcut is a very good idea.
Windows 2012 R2
The steps were:
- Remove PowerCLI 6.5
- Install the PackageManagement PowerShell Modules Preview (which will self-update with newer package management cmdlets)
- Install PowerCLI 11 per Install-Module
- Create the Desktop Shortcut to ensure the Import-Module is done every time the new PowerCLI shortcut is launched
Now, these steps for Linux have been integrated into a PowerCLI installer located within my GitHub repository. This installer installs not only PowerShell but also the VMware PowerCLI and PowerNSX modules. While it installs PowerNSX, PowerNSX will not load due to known issues with the latest PowerShell Core. PowerNSX has been kept in the installer in the hope that those issues will be fixed.
Granted, you could use the much older version of PowerShell on Linux, but that requires much older versions of PowerCLI as well. I am hopeful that the PowerNSX will eventually support the released version of PowerShell for Linux.
Why PowerShell for Linux? I use many Linux systems over Windows systems and want to have available all tools at my disposal. There is often a debate on which scripting language to use. I really have no debate. I use what is best for the job at hand or what comes from others. In effect, I use the tools at my fingertips instead of trying to recreate the wheel.
My installers could be called from Ansible or other tools, but they are designed to be simple get-you-going scripts that take into account SELinux and other security mechanisms like firewalls, etc. They are really simple shell scripts. Eventually, as a learning exercise, I want to port them over to Ansible. However, my choice to use simple shell scripts is a result of the need to keep the systems I use as lean as possible.
The PowerCLI installer installs only what is required on top of the smallest image possible of Linux. They can be used on any distribution as well. These are really bootstrap scripts. Just to get Ansible running, for example, you still need to bootstrap the target operating system in some fashion. These scripts are part and parcel of the bootstrap process.
Installations of the latest versions of PowerCLI are different for Windows and Linux but are useful on both operating systems. Versions matter.