Ok last week I was in Russia so I missed out on the weekly lesson. In this lesson I want to demonstrate the idea of how PowerShell is object orientated. Just about everything you work with in PowerShell is an object and objects have members known as properties and methods (actions). I’m going to use a very common analogy to get the idea of objects across using the tried and test “objects are like a bicycle” method.
Here is a picture of a bicycle.
There is something very common about bikes they usually have the same parts (properties) and usually perform the same actions(methods). So common parts include wheel, seat, pedals and brake. Whilst common actions include move forward, steer left, steer right and brake. So if a bicycle was a PowerShell command or an object you were working with like a VM then you would expect to work with its properties and methods.
In comparison if we where to look at some examples of the properties of Get-VM cmdlet object we might expect to see:
So a property of a VM might be the amount memory allocated to VM is found by view the MemoryMB property.
To find out what type of properties and methods (members) an object or cmdlet has you could pipe the cmdlet through the Get-Member cmdlet or using its alias gm
So we haven’t really talked about any new PowerCLI cmdlets this lesson so let’s spend some time learning a few new commands.
Let’s look at useful command that can help you work out which Get- cmdlets that are used with the PowerCLI (vmware). If you filter the Get-Command cmdlet to search on verbs that start with “get” that are associated with vmware module.
So right near the top is the Get-Cluster cmdlet. If we run it we get the default output which is all the clustered associated to the vSphere vCenter implementation that we are connected to.
If we look at the properties of Get-Cluster we manipulate its Drsmode property for example to see the automation level set for DRS. One way we can do this is by passing the result (an object) into a variable which is also an object. We can the view the details of this variable by looking at its properties. We’ll talk about variables in more detail in another lesson. For now just know to define a variable you just declare it by placing a $ sign in front of a meaningful word then making it equal to the said object which in our case is the result (an object) of running the Get-Cluster cmdlet.
Now we can view its DRSmode property.
Ok you can look around the rest of the Get- (PowerCLI) cmdlets as homework. Try not to do anything destructive at this stage 😉 and that concludes lesson 3.
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.
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.