PowerCLI: Lesson #1

Ok before we begin I have to pay homage to where I’m getting my learning material from.

1. To learn PowerShell I’m using the Microsoft “Windows PowerShell step-by-step” book.

2. To Learn PowerCLI initially I’ll be referring to Hal Rottenberg’s Book “Managing VMware Infrastructure with Windows PowerShell “  and Trainsignal Pro Series Vol1 CBT (Hal Rottenberg)

3. I’m sure some were down the line I’ll be referring to the UK guru for PowerCLI Alan Renouf, http://www.virtu-al.net/

4. And if I really have to RTFM then its opening up the Admin guide found : http://www.vmware.com/support/developer/windowstoolkit/wintk40u1/doc/viwin_admg.pdf

 The first steps should be to install:

Step1 Download and install PowerShell from Microsoft if your Operating system doesn’t already have it installed.

Step2 Download and install PowerCLI from VMware

You should then see an icon on your desktop like this:

This is PowerCLI console. It’s actually a PowerShell script that prepares a PowerShell console with the VMware snap-in and some initial useful information like popular PowerCLI commands.

Alternatively you can open up a standard PowerShell console and use the following command-let to manually add in the VMware snap-in:

Step 3.

Now you are ready to go and connect to your vCenter or ESX server using the following command:

You will be prompted with a certificate error which is normal unless you decided to use a trusted root certificate/authority with your vSphere deployment:

You will then be promoted to provide your vSphere credentials, so enter you username and password:

You can enter these parameters at the command-line too but we’ll see that in a later lesson.

Step 4

Now we are connected to our VMware environment let’s do something useful.  Let’s run a popular PowerCLI command-let, Get-VM which lists all the VMs from the root level of your inventory and provide some rudimentary information like how many CPUs and how much memory each VM has:

So in layman’s terms I’m going to try to explain what’s going on.  PowerCLI command-lets  are based on .Net libraries used to interface with VMware’s vSphere SDK (API) . VMware has developed a mature, feature rich, extensive and powerful API for its ESX/vCenter platforms. This API is interfaced using web services which allows anyone to develop VMware applications using just about any language including me (see my downloads section).

When connected to the API it offers up the Virtual Infrastructure in the form of a hierarchical inventory or tree of objects:

These objects include ESX servers, VMs , DataCenters and so on. These objects have properties and actions (methods) that can be performed on them. For example a VM could have a properties which holds a value that shows how many CPUs are configured on this VM or a method which when manipulated can change the power state of a VM to off or on.

This SDK exists both on ESX and vCenter and is all most exactly the same on both platforms expect the vCenter version has a few more objects to manage the feature you wouldn’t normally see on a standalone ESX server like DRS for example:

You’ll often hear the term Managed Object Reference. The way I perceive this term is that when you are manipulating an object like a VM what’s actually happening is you are presented with a  reference to the object which you can work with locally and changes are sent down the line for the SDK to action within vSphere. This allows you to work with a great number of objects locally without the overhead of constantly to refreshing the inventory.

I know this is a lot to take in but it’s the only way I can think of explaining it so non-developers would understand it.

The beauty of PowerCLI is you don’t have to be a developer and the pain-points of developing the SDK to perform the tasks you would like to see are transparent and masked away (simplified) so you don’t have to worry about them.

We have looked at 2 lines of code which first helped us connect to vSphere and secondly list out all the VMs. Now if I had to do that let’s say in C# languages with the SDK it would take 40 to 50 lines of code.

 We’ll leave it there for lesson#1 and look out for lesson#2 shortly.

Previous – Next