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.
Another great reason to move to PowerCLI for VMware management in our environment is that current and future version of Microsoft products, which my group also administers, will be largely manageable from PowerShell.
Some examples that I have found useful so far:
Storage VMotion a VM
Connect to vCenter or an ESX server using connect-viserver.
[sourcecode lang=”powershell”]Get-VM "VMNAME" | Move-VM -datastore (Get-datastore "DATASTORENAME") -runasync[/sourcecode]
Show VMs that have Raw Disk Mappings
Connect to vCenter (its most useful in an entire datacenter, but works against an ESX hosts also).
[sourcecode lang=”powershell”]Get-VM | Get-HardDisk | Where-Object { $_.DiskType -like "Raw*"} | `Select-Object -property @{N="VM";E={$_.Parent}},DiskType,Name,ScsiCanonicalName,DeviceName,CapacityKB[/sourcecode]
Another big reason I’m glad we were exposed to PowerCLI at this time is we all know the future roadmap of vSphere. The next major release will remove the ESX version of the hypervisor and only include the ESXi (console-less) hypervisor. Once we make that migration, things we have done in the past will no longer be possible. By moving to remote command-line administration today, we are curbing some of our pain of moving there when we also move to the new vSphere release.
PowerCLI for HP EVA best practices of VMware settings
But, as I wrote about when we found the EVA best practices, we still need to modify some other settings on the hypervisor — specifically chaning the IOPS value for LUNs is recommended in HP’s best practices. So, in the past week, I have been looking at how to do this from PowerCLI. I have not written about this, but our EVA’s have been having a large amount of issues in the recent months. One reason I have not written anything is that we still have not gotten a root cause for our problems. But, we have been working extensively with HP’s senior level support team for a few months now. One of the things we looked at was our ESX configuration and once again, we were sent to their best practices document for VMware. Fortunately, we already had their recommendations in place, so there was little to worry about. But, going back and looking at these settings again, we were able to find ways to set these settings (without reboot to boot) using PowerCLI instead of using command line from the ESX console. So, I certainly wanted to share these, along with the sources where I found them, for anyone using HP EVA in their environments. Set the Multipath Policies of a Host to Round Robin from PowerCLI (for HP EVA best practices) Connect to vCenter
[sourcecode lang=”powershell”]Get-VMHost <hostname> | Get-ScsiLun -CanonicalName "naa.600*" | Set-ScsiLun -MultipathPolicy "roundrobin"[/sourcecode]
Remember, that for the hostname, you can use wildcards to get all the hosts in a cluster or simply a * for all hosts!
>> Source
Set IOPS values of disks to 1 from PowerCLI (for HP EVA best practices)
Connect to an individual ESX host for this. Its cumbersome, but provides the functionality.
[sourcecode lang=”powershell”]$esxcli = Get-EsxCli
$esxcli.nmp.device.list() | where {$_.device -like "naa.600*"} | %{
$configBefore = $esxcli.nmp.roundrobin.getconfig($_.device)
$esxcli.nmp.roundrobin.setconfig(0,$_.device,[long]1,"iops",$false)
$configAfter = $esxcli.nmp.roundrobin.getconfig($_.device)
# Uncomment the following lines if you want to report the settings
# $configBefore
# $configAfter
}[/sourcecode]
>> Source
