Its pretty easy to see where I stand on PowerCLI from the headline on this entry. Â Disclaimer, I haven’t used it extensively, but I can already see the why VMware has chosen to embrace PowerCLI for scripting. Â These are some of my initial thoughts after some light usage — in short, I think PowerCLI is extremely powerful.
Up until January, we had scripted everything for VMware in VI-Perl.  I don’t begin to call myself a Perl programmer, but I can crawl in and modify a canned Perl script and I am able to make it do what I want. That said, it was always a pain to do it.
For our VMware environment, we have monitoring scripts that report low disk space for our guests, a daily snapshot report and what VM’s have been provisioned or deleted from the system. All of these were things I had to find scripts that had already been written in VI-Perl, and so we relegated scripting to simply monitoring in our environment. After we added the VMware Management Appliance to our network, we used it occasionally for Storage VMotion in the ESX 3.5 days, before it was added to the GUI.
With PowerCLI, however, we have moved into doing more actual configuration and changes — real work — using it. Because PowerShell support piping the objects between commands, we have quickly realized gains in efficiency by retrieving a list of targets and issuing a command against the group. Some things we have done manually in the past make much more sense in PowerShell. Performing a VMotion or Storage VMotion is a good example of this. Storage VMotion involves a number of steps (click, click, click, click, click) to perform in the GUI. In Powershell, its a simple, one-line and easy to understand command.
PowerCLI is much more user friendly to me than writing Perl. Soon, I plan on rewriting my management scripts using PowerCLI. There are some security related things I must figure out (haven’t even looked into them yet) – like signing PowerShell scripts with a certificate, which will be required for executing scripts on a schedule. (In our environment, we plan on making all of our PowerShell instances run in remote-signed execution policy to maintain security.
