PowerCLI from OS X/Linux etc.

So, at times I would go to extremes to try and make something work the way I want. Now this post may not be helpful to most people. But if you ever wanted to execute powercli from your non windows machine read on.

Disclaimer: I will not recommend this for any production environment. This is just what I did in my lab to avoid the extra RDP session I would have to make to a windows machine to get to PowerCLI. If you decide to use this and find yourself in the hot seat, don’t blame me for it 🙂

First thing is first, install PowerCLI on a windows machine. Yes you will still need to install it on a windows box. As of 03/08/2012, you can download PowerCLI from here.

Once you have installed PowerCLI, do one quick thing (this is not required but it would just make things a little easier). Copy the PowerCLI shortcut from your desktop and drop it in the root of C, this will result in easy access for later. You can also mess around with the environment variables if that suits you better.

The next task is to install a SSH server on this windows machines (where you installed PowerCLI). Pick your favorite from the list below, I am sure there are more than what I listed below.

The list above is in no particular order, pick whichever one you prefer. I went with WinSSHD and the install was pretty straight forward. Once I installed WinSSHD, I took all the defaults and port 22 for ssh. I had to give a local account admin access which was pretty straight forward as well. You can also use domain accounts if you get the paid version. The only thing after adding the admin account is that you have to start the WinSSHD service from the WinSSHD control panel.

Once SSH is running on the windows machine and you have PowerCLI installed, you are all set.

Go back to your non-windows machine in my case its a MBP running Lion 10.7.3.

  • Start terminal
  • type “ssh username@ip/hostname” username is the same user that has ssh access and ip/hostname is of the one where you have PowerCLI and SSH server running
  • You will be prompted for password, go ahead and enter that in
  • You will now be looking at the command prompt of your windows box (yoohooo!)
  • Remember I had you copy the PowerCLI shortcut to the root of C? Now go to the root of C and execute the shortcut to look at your fresh PowerCLI prompt on your non-windows machine

  • Once you run the above file, you will be sitting at the PowerCLI prompt where you can make your connection to the vCenter

  • One thing that I wanted to point out. I created a local user on my windows machine that had SSH access. This local user did not have access to vCenter. Because of this I think, when I ran Connect-VIServer vCenterServerName, nothing happened. I had at least hoped for a login prompt but nothing. So I ended up supplying the credentials in the command line and that worked.

Connect-VIServer vCenterServerName -User YourvCenterUsername -Password YourPassword

  • What’s next? Well run all your PwerCLI commands from your non-windows machine. Technically you are still running it on Windows because you have SSHed into your windows box, but port 3389 can go away now as port 22 will do the job 🙂

Again, please keep in mind that this is really a do it at your own risk sort of thing. If you decide to by cowboyish, thats your own decision not mine. I will probably let this setup run for sometime in my lab to see if I find any caveats.

Changing PSP using Powercli

Ok I will admit I am not the best thing there is when it comes to scripting, but powercli gets me fascinated because it speaks English. The other day I found myself performing a boring tedious task, updating the Path Selection Policy (PSP) for the hosts. There was only one issue, we had 32 hosts with 5 datastores and a couple hunderd more hosts in other sites. You already know that the PSP is done for each datastore which meant that I would have to do each datastore on each host and confirm it changed. That is just super gross if you ask me, besides it is also a recipe for making errors and missing stuff. Powercli to the rescue.

After getting conneced to your vCenter in powercli, the folowing will display the PSP for all the DS attached to that host:

Get-VMhost ESXHOST/IP | Get-ScsiLun -LunType disk

Where ESXHOST/IP is the hostname or IP of your host. This will print a nice list of all PSP settings for each datastore this host sees. But what if you want to see this at the cluster level?

Get-Cluster CLUSTERNAME| Get-VMhost| Get-scsiLun -LunType disk

Where CLUSTERNAME is the name of the cluster in vCenter against which you want to run this query. This will display the PSP settings for all hosts in this cluster for all their datastores like below.

Of course I have blocked out my cluster name for obvious reasons, but there are two things that are highlighted above in red and yellow. The one in Red is the canonical name that we will need later and of course the one in yellow is your current PSP setting.

If you want to change the PSP setting for all the datastores on a host that have their canonical name starting with “naa.500….” like in my case, this is what you would do:

Get-VMHost ESXHOST | Get-ScsiLun -CanonicalName “naa.500*” | Set-ScsiLun -MultipathPolicy “roundrobin”

The above will change the PSP to Round Robin for all LUNs on this host that have the canonical name starting with “naa.500….”. What if you want to do this cluster wide?

Get-Cluster CLUSTERNAME| Get-VMhost| Get-scsiLun -CanonicalName “naa.500*”| Set-ScsiLun -MultipathPolicy “roundrobin”

The above will take care of that and you will be able to update and confirm the change in no time versus clicking around in vCenter forever. You can simply run “Get-scsiLun -LunType disk” on your cluster once this has completed to confirm that all devices see the updated PSP.

There are some awesome scripters (and I am not one of them) around that will make this whole thing a one click deal, but if you are looking for one liners, whats mentioned above will do.

Of course what path policy to choose is way out of the scope of this post. Be careful about what you select and check with your storage vendor/array/guru  as well, this is a nice kb article. Be aware of round robin and MSCS VMs as mentioned in the KB article.

Backup/Restore config for ESXi using vMA

With the rise of ESXi I have often found myself simply redeploying the hypervisor in order to overcome an issue. Why? Because it literally takes minutes to reinstall ESXi and when you have a big customer being effected by an outage, your first priority is to bring the environment up. Yeah you still have HA and what not, but you still need to bring all the hosts in the cluster up and functional as soon as possible so that you dont find yourself in a situation where you have lost another host. Yes, I am all for finding the root cause but sometimes my curiosity is not as important as the customer’s application. In reality it never is. Plus what if your cluster just happens to be a two host cluster (dont ask me why, but I have seen that as well), in this case bringing the other host up is of paramount importance unless you dont mind being caught with pants down.

So let’s say you reinstall ESXi and that really takes a few minutes. However their might be things you do to customize your hosts like licensing info, multipaths, local users, switchs etc etc. I think you get the idea. Soon you will realize that its really stuff like this what ends up consuming your time. So what you do? In comes vMA. You can use vMA to backup your host configuration to a file and use that file to restore the changes you made to the host. This will save you plenty of time. Follow these simple steps.


Login into  vMA and set the vifptarget to the server you want to back up. To do that run:

vifptarget -s servername/ip (This is assuming you have already added the server in question using the vifp addserver command — fast pass)

Once the target has been set

vicfg-cfgbackup -s /location/BackupFileName

Your host configuration is now saved.

If you dont want to do a vifp addserver and then set the target to this host in vMA for whatever reason, you can also run:

vicfg-cfgbackup -s -server IPaddrOfHost /location/BackupFileName (This command will prompt you for a username and pwd as the vMA appliance doesn’t have this. Note the -s stands for save).

You can then FTP or SCP into the vMA appliance and grab this configuration file and store it in a safe/accessible location. Notice I said “accessible” because its important for you to have backups, but these backups are not of any value if you can’t get to them when you need ’em.


You can restore the configuration using the following command from your vMA appliance:

vicfg-cfgbackup -l -server IPaddrOfHost /location/BackupFileName (Note the -l stands for load)

You will be prompted for a username and password and you will also have to type YES as the prompt will say.

Keep in mind you will have to reboot your host after the restore completes.

Some use cases:

Let’s say you accidentally deleted a vswitch on your host. Instead of trying to replicate what another host has and increase your chances of missing a thing or two (maybe promiscuous mode was enabled as you run an IPS device on this host/cluster), you can simply use the above command to restore the backup for this particular host, restart your host and you are all set.

You decided to reinstall ESXi on the host. You will notice once you begin that process your host in vCenter will now be down. As you complete the install for ESXi and assign your host the static IP addr, you can then restore the config using the above commands and reboot your host. Log back into the vCenter and try to reconnect the host. The agent will get redeployed on this host and once that is completed, you will notice that all your settings are in place and DRS can happily move VMs on this host.

You can probably use powercli/vcli to do the same. My personal favorite is vMA although I use powercli/vcli for other things.