VMware related material
In this lesson we are still focusing on the basic fundamentals of PowerShell. I know this section should be about PowerCLI but without understanding the fundamentals of PowerShell then nothing we discuss about PowerCLI will make sense. I will still try to throw some PowerCLI cmdlets into the mix though. So that being that I did promise to talk about PowerShell variables in more detail so here we go.
Using variables in PowerShell allows you to store objects or details in to an area of memory for later use. Without the use of variables it would be more or less impossible to perform calculations with PowerShell or even do things like manipulate filtered data. This becomes important in terms of managing VMware using PowerCLI as the amount data stored in the form of objects (VMs for example) and properties retrieved from VMware is immense.
Let’s simplify: A Variable is a dedicated area of memory in which you store information in for temporary use. You can create a variable to hold the number “5” then later with some calculations you could change the number to “10”. This value is always referable to while the variable exists. Variables are not restricted to numbers. You can create a variable to hold a string of text known as a string variable, or even a date or even an object like a VM with all its properties.
Below is a list of some types of variables that can be created in PowerShell.
|[datetime]||Date or time|
|[string]||String of characters|
|[double]||Double-precision floating number|
|[single]||Single-precision floating number|
|[wmi]||Windows Management Instrumentation (WMI) instance or collection|
|[adsi]||Active Directory Services object|
|[Boolean]||True or False value|
It also has to be noted that there are predefined variables which we’ll look at in a later lesson. Also all variables are listed in the PowerShell variable provider, again something for another lesson. We need to keep it simple until later.
In other development languages it’s often required that you predefine a variable with the type of data that it will store, for example a number or a string. In PowerShell that’s not necessary. PowerShell cmdlets and scripts are short lived unlike an application that you might create using C# or VB. So it’s common to declare the type of variable you will use with these languages to optimise the memory space required by the variable.
In PowerShell you create a variable by choosing name for the variable and preceding it with a $ character. for example:
You can then assign a value to that variable using the assignment operator (we’ll talk more about operators in a later lesson) which is the = character. So for example if you wanted to assign the $myvariable with the number “5” then you would enter:
Officially you could use the New-Variable cmdlet to create a variable but no one does that from the command-line.
So the next thing to know is once we have a variable declared we are now playing with objects. If we create the $myvariable variable it is too an object and just like all objects it has properties and methods (as described in lesson #3). If we create a string variable $mystring and assign it some text we can manipulate this object with its properties and methods. Different types of object have different methods and properties so let’s take a look see.
We first create and assign the variable and pipe it though Get-Member (gm) to see its methods and properties.
As this is a variable of type “string” so we can do stuff to it as if it was a string.
So we could call its ToUpper method which would display the text in Uppercase.
Calling this method doesn’t actually change the value in memory and you’d notice that when I try again to call the string without the ToUpper method nothing has changed since we first assigned the string.
Ok so let’s jump back into PowerCLI for the last section and apply what we know about variables with what we learnt in previous lessons.
If you remember we can list out which of our VMs are in powered off state by filtering the Powerstate property of VM Object. Now what we can do is store that list of a VMs in a variable object like so:
Now we can treat this variable like a VM object. To prove my point lets list its members (methods & properties)
So now if we want to start this list of VMs and we have to do is just pipe the variable into the Start-VM cmdlet:
Ok let’s call that a day for variables.
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.