PowerShell Tips Corner
Area dedicated to working with Powersehll in a virtual Environment.
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.
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.
Lesson # 5
Ok if you look back at Lesson #3 we talked about a command to list out all the PowerCLI Get- cmdlets, which was >gcm –Module vmware* -verb get well let us come back to that now. Its traditional for PowerShell cmdlets to be constructed like so:
Verb-MeaningfulWord for example Get-VM
Well Get- isn’t the only verb used in PowerShell, you’ll also find:
- Add– (there are only 3 of these in PowerCLI)
We’ll try and spend this lesson looking at some more PowerCLI cmdlets before spending more time on PowerShell fundamentals.
So we know how to list all the PowerCLI cmdlets but how do we find out how to use them? Well we have different options.
- Read the help that comes with the command
- Refer to the Guru’s :
- Or just plain old Google it.
So I listed the PowerCLI Get- cmdlets and found a command Get-VMHost and wanted to learn how to use it. So I probed its help by placing “-?” after the cmdlet like so:
This is great to give you an insight in to the parameters to make the cmdlet work but I needed an example. If you look at the bottom of the help output you see it provides you with a way of showing some examples:
From this information I was able to see that the Get-VMHost cmdlet is used for finding out which host a VM is running on within a specific datacenter. So I tried it for myself:
a) We run the Get-VMhost cmdlet
b) Use the –Location switch to pass in the name of the datacenter.
c) We use the Get-Datacenter cmdlet to pass the object of the datacenter into the location parameter.
d) Use the –VM switch to pass in the name of the VM.
e) We use the Get-VM cmdlet to pass the object of the VM into the VM parameter.
And the result is the host system information that the VM “VeeamRicky” is running in.
So you can see it didn’t take much to substitute my lab information into the example to make the whole string of commands to work.
Now following on from that, what if we don’t know the Datacenter name! Well we can of course run the Get-Datacenter cmdlet which will enumerate the datacenter’s associated with you vCenter. Now in my Lab I only have one but if you have a few what you could do is store the enumeration in a variable.
>$mydatacenters = Get-Datacenter
So if we looked into the variable we see server entries potentially that are indexed for example:
 VeeamUKVsphereDatacentre1 Datacenter-datacenter-21
 VeeamUKVsphereDatacentre2 Datacenter-datacenter-22
 VeeamUKVsphereDatacentre3 Datacenter-datacenter-23
Because this an enumeration (collection) then your variable is holding multiple entries. This format of a variable is known as an Array. A single entry can be referenced by call the variable with an index like so:
> Name Id
So in our Get-VMHost cmdlet we can substitute the Datacenter query with a our variable like so:
>Get-VMHost -location $mydatacenter -VM (Get-VM -Name “VeeamRicky”)
And if you wanted to you could do the same with VM list retrieved with the Get-VM cmdlet
OK let’s break off there. Look out for Lesson6.