I’m starting a new section on my Blog. I’m going to make a real effort to learn Powershell and PowerCLI for something else I’m doing so I have decided to using the learning experience to create a new section. I have made several effort to before but because I have no need to use it in my job I’d get distracted and move on to some other project. This time I committing and my knowledge gain could be useful as tutorial to others.Look out for lesson#1
Popularity: 24% [?]
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:
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.
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.
Popularity: 64% [?]
As I go through this serious of lessons on PowerCLI I’m going to try to expose the basics of PowerShell in the same lessons. 2 for the price 1. I’m going to initially deliver them in very small nuggets scaling larger as we advance into more detailed stuff. So in this lesson I’m going to look at a some core fundamentals of PowerShell whilst applying the theory to PowerCLI.
First let’s look at a process known in PowerShell as the “pipeline”.
Most cmdlets (commands) provide some form of output when you run them, for example when we ran the Get-VM the output was a list of VMs and some basic information. With the “pipeline” function we can take this output and process it through a follow-up cmdlet. This is done by placing the | character after the command then entering the follow-up command. We can use another cmdlet Where-Object to filter out information from the properties of the previous cmdlet.
Now we mentioned in lesson 1 that cmdlets have properties and methods and one of those properties found with the Get-VM cmdlet is PowerState which you can guess it is used to report the power state of a VM (powered off, on etc) . So to list all VMs that are powered off we would run the Get-VM cmdlet and pipe it into the Where-Object cmdlet and would look like this:
So when we execute that command we get a list of just the powered Off VMs:
Change the command to filter “PoweredOn” then we just get the powered On VMs:
So how do we find out what properties of the Get-VM cmdlet we can filter on. Well like any cmdlet we find out what properties and methods (actions) are available by passing (piping) the cmdlet into a another cmdlet to find the results. If you pipe any cmdlet into the Get-Member cmdlet the output will be a list of properties and methods. You can also use a predefined alias (alias use to abbreviate cmdlets) for Get-Member which executed by entering gm . So to get the properties and methods of the Get-VM cmdlet you could use:
So let’s take this idea one step further, let’s use a cmdlet Start-VM and I bet you can guess what that does… Let’s use it to start all the powered off VMs by piping what we know into it like this:
Which will start all the VMs that have the Power State of Powered Off.
Ok last thing I want to do here is just explain something about piping. The result of the Get-VM although look like a load of text is actually creating a list of objects (VMs in this case) . So the Start-VM cmdlet isn’t actually trying to start a VM called “SCOM PoweredOff 1 256” it just takes the Name property value as the reference for the VM which in this case is “SCOM” and starts a VM with the same name.
In a later lesson I’ll try an explain Objects as PowerShell is an object orientated scripting language so it’s very important but for now look out for lesson#3.
Popularity: 90% [?]