If your daily job involves work with VMware infrastructure and you are still stuck in the GUI, then you are really missing out. For several years now, VMware has offered a PowerShell management solution that for many VMware professionals has proved indispensable. Over the next few articles I’m going to introduce you to the world of VMware vSphere PowerCLI and demonstrate how easy it is to manage your VMware environment. I’m going to keep it pretty simple, but as you gain experience and familiarity you’ll quickly realize how easy it is to scale.
(Need to catch up? Check out the rest of this series! In part two: setting up and configuring PowerCLI. Part three: use PowerCLI to start and shutdown VMs. In part four: PowerCLI and PSDrives, and in part five: created a new VM. Finally, in part six: use PowerCLI to manage your ISO files.)
Downloading and Installing PowerCLI
Yes, PowerCLI is PowerShell based,which primarily means typing at a console prompt. But I think you’ll find that even if you have very little PowerShell experience, you can get a lot accomplished with very little typing. Of course, the more PowerShell experience you have, the more you can accomplish.
The first thing you need to do is download the latest version of vSphere PowerCLI. Even though the product has the vSphere moniker, you can use it even if you have a single ESXi server. In fact, that is all I will be demonstrating with. So download and install the package. You should be able to accept all the defaults. The whole point is to manage from your desktop and the install should go on just about anything that runs PowerShell 2.0 or later (which is the minimum PowerShell version you should be using anyway).
After installation you will see some shortcuts in the Start Menu for VMware vSphere PowerCLI. On 64 bit systems you’ll also see a link for 32 bit. Go ahead and launch the appropriate version. This will open a new PowerShell session and automatically load the PowerCLI PowerShell commands. If you are using PowerShell profile scripts, they too will run, but in the end you should end up with something like this.
My profile changes my path to a custom PSDrive. Your prompt will be different.
Getting Started with PowerCLI
To discover what you can do, you can use the Get-VICommand. Running Get-PowerCLIHelp will launch a CHM based help window.
Although once you know some commands you can also use PowerShell help to view documentation.
What I especially like is that VMware offers online help as well.
PowerCLI Scripts: help connect-viserver –online
You could do all of your PowerCLI work in this session, but if you are like me, you’ve already configured a PowerShell session and console, so why not simply add the PowerCLI bits? Type Exit to quit this session, and let’s add the bits ourselves.
This is quite easy. All of the PowerCLI commands are packaged as snap-ins, as opposed to modules. This means you have to run the install on any computer on which you want to use them. You can see all of the registered snap-ins in your session:
PS C:> Get-PSSnapin VMware* -Registered
Before you can use any PowerCLI commands, you need to add the snap-in to your session. To get started, all we need is the core snapin.
PS C:> add-pssnapin vmware.vimautomation.core
You can also use wildcards.
PS C:> add-pssnapin vmw*
Once loaded, I can use Get-Command to view the commands.
PS C:> get-command -Module vmware.vimautomation.core
That’s all the Get-VICommand tool is really doing. As you can see, there are many commands at our disposal.
The best part is that if you know PowerShell, you can easily incorporate these commands into your work with very little effort.
PowerShell Caveats
There are a few potential gotchas, especially if you are running PowerShell 3.0. First off, because the commands are packaged as snap-ins, you don’t get autoloading of commands like you may be used to. PowerShell will automatically import modules when you use one of the commands, but this feature doesn’t apply to snap-ins.
Also, if you happen to be running, or have installed, the Hyper-V module, you will run into naming collisions. For example, Microsoft and VMware have a Get-VM cmdlet. If you run Get-VM you most likely will get the Hyper-V cmdlet. Unless you’ve added the VMware snap-ins, in which case you’ll get the PowerCLI version. There are a few ways to mitigate.
First, you can preface the command with the module name.
PS C:> hyper-vget-vm
Or, import the Hyper-V module and use a prefix.
PS C:> import-module hyper-v -Prefix MS
Now, all of the Hyper-V commands will have a MS prefix, eliminating the collision.
PS C:> get-msvm chi-dc01 Name State CPUUsage(%) MemoryAssigned(M) Uptime Status ---- ----- ----------- ----------------- ------ ------ CHI-DC01 Running 0 621 01:14:32 Operating normally
Because PowerCLI does not require PowerShell 3.0, but the Hyper-V cmdlets do, I tend to run PowerCLI in separate session running PowerShell 2.0. Create a shortcut for this command:
powershell -version 2.0 –noexit -command "&{add-pssnapin vmware.vimautomation.core; $host.ui.rawui.WindowTitle='PowerCLI'}"
The window title is optional. Configure the shortcut with whatever size and colors you’d like. But now I have a PowerShell window more to my liking and I don’t have to worry about name collisions. If you don’t have to worry, then you can ignore all of this and simply add the snap-ins when you need them.
For now, I encourage you to download and install the latest PowerCLI package. In the next article in this series we’ll look at connecting to a server and begin exploring the possibilities.