10 Steps To Kick-Start Your VMware Automation With PowerCLI - Simple Talk

11/15/2016
10StepstoKickStartYourVMwareAutomationwithPowerCLISimpleTalk
Simple Talk
A technical journal and community hub from Redgate
02 JUNE 2010
10 Steps to Kick-Start Your VMware

Automation with PowerCLI
Virtualization is a powerful technology, but it comes with its own host
of monotonous and time-consuming tasks, no matter how big or small
your organization is. Eliminating these mind-numbing tasks (and the
potential for error which they bring with them) is a goal with striving
for, and well within your reach. Jonathan Medd explains.
Jonathan Medd
Virtualised environments can range pretty wildly in size; from one physical
server in a small business or test lab with a few VMs, right up to large
enterprises with hundreds or thousands of physical servers and
seemingly limitless VMs. Whatever the size of your environment, as a
good system administrator, you know that its important to congure it in
a consistent manner, and automate as much as is reasonably possible.
If youre using VMware ESX / ESXi hypervisors and vCenter as the
management software, then you already have access to a number of
automation tools to assist with making your infrastructure function as
smoothly as possible. These include VMware vSphere PowerCLI, VMware
vSphere CLI and VMware vSphere SDK for Perl. In this article, I will be
focusing on VMware vSphere PowerCLI, the automation tool supplied as a
snapin for Microsofts Windows PowerShell command line tool and
scripting language, as well as 10 ways that any system administrator can
kick-start the automation of their virtual infrastructure.
Getting Started
As I just mentioned, vSphere PowerCLI is provided as a snapin for
Microsofts Windows PowerShell, and so to use it you will need:
https://www.simpletalk.com/sysadmin/virtualization/10stepstokickstartyourvmwareautomationwithpowercli/
1/14
11/15/2016
.NET Framework 2.0 SP1

Windows PowerShell 1.0 or 2.0
Note
If you have Windows PowerShell 2.0, then Id advise installing
.NET Framework 3.5 SP1, since youll then have access to the
built-in PowerShell ISE and cmdlets (such as Out-GridView).
Of course, you should always refer to the VMware website for up-to-date
system requirements. At the time of writing, PowerCLI is currently in
version 4.0 Update 1, and is supported on the following 32 bit and 64 bit
platforms:
Windows Vista
Windows XP SP2
Windows 2003 Server SP2
PowerCLI itself will connect to and manage:
VMware ESX 4.0 Update 1/vCenter Server 4.0 Update 1
VMware ESX 4.0i
VMware ESX 4.0/vCenter Server 4.0
VMware ESX 3.5
VMware ESX 3i
VMware VirtualCenter 2.5
VMware ESX 3.0/VirtualCenter 2.0
There is also a separate PowerShell snapin available for VMware Update
Manager, which is the tool provided as an accompaniment to VMware
vCenter to centrally manage the patching of ESX / ESXi hosts and guest
virtual machines. This snapin has similar system requirements to the
main PowerCLI tools, although it must be noted that these cmdlets
require VMware vSphere PowerCLI 4.0 Update 1, and will only work with
VMware Update Manager 4.0 U1. So, if your vCenter is the base 4.0
2/14
11/15/2016
release or earlier, you will not be able to use them, and youll need to
upgrade.
Both of the above sets of cmdlets can be found and downloaded from the
VMware PowerCLI site, which is a great reference site for everything
needed to get started with PowerCLI. If you really get stuck, there are
experts waiting in the forums to answer any queries you may have. Bear
in mind that when youre getting started, it is likely that the majority of
your questions will already have been answered in these forums, and a
simple search will nd those answers.
Once all of the system requirements have been installed, the PowerCLI
cmdlets can easily be accessed via the shortcut which the installer places
on the desktop. Alternatively, if youre already familiar with Windows
PowerShell, you may simply want to add the VMware snapins to your own
session. If youre unsure how to do this, you can just use the AddPSSnapin cmdlet to make these cmdlets available to the current session,
as shown below:
StandardPowerCLIcmdlets
AddPSSnapinVMware.VimAutomation.Core
VMwareUpdateManagercmdlets
AddPSSnapinVMware.VumAutomation
For regular use, it would make sense to add these to your default
PowerShell prole, which can be opened by entering this command from
within PowerShell:
notepad$profile
This will open a text le containing the custom conguration to run each
time a PowerShell session is opened. If you receive an error that the
prole le does not exist (i.e. one has not yet been created), a prole le
can be simply created via:
NewItemPath$profileItemTypefileForce
Once youve got your prole open, you just need to add this line to it:
3/14
11/15/2016
AddPSSnapinVMware.VimAutomation.Core,VMware.VumAutomation
The nal step to getting started with PowerCLI is to make a connection to

either VMware vCenter or directly to an ESX / ESXi host; this is similar in
concept to opening the vSphere client and making a connection to
VMware vCenter or directly to an ESX / ESXi host. Use the ConnectVIServer cmdlet to make the connection to VMware vCenter:
ConnectVIServervCenterServerName
or a host, if directly conguring a host:

ConnectVIServerHostServerName
The system will use the credentials you are currently logged-on with to
establish a connection with the target. Alternative credentials can be
specied with the -Username and -Password parameters, if necessary. If
the current credentials are not sufcient, then you may be prompted to
enter more appropriate credentials via a standard Windows dialogue box.
10 Steps to Kick Start Automation

Now that youve got your VMware automation tools congured and
connected, its time to look at how to use them to get as much of your VM
maintenance automated as possible. As youll see, Ive broken this kickstart process down into bite-sized steps to make it easier to follow. These
steps are individual stand alone operations, although they can be scripted
to make powerful combinations. Taken together, all 10 steps will give you
a solid foundation for putting some more sophisticated automation in
place. Before you get started, I recommend downloading Alan Renoufs
excellent Quick Reference Guide (PDF), just in case you want to look up
the details of any of the cmdlets Ill be discussing.
1) Reviewing and Conguring Virtual Machines

The reason virtual infrastructures are put together is primarily (and
unsurprisingly) to run virtual machines, so a good place to start is with the
Get-VM cmdlet, which can produce a simple inventory of all VMs currently
4/14
11/15/2016
found within VMware vCenter . Using the Get-VM cmdlet, and the
standard PowerShell Select-Object cmdlet, you can retrieve the particular
properties that are of interest and use Export-CSV to export that data into
the ever-useful CSV le format for further manipulation and distribution.
GetVM|SelectObjectName,NumCPU,MemoryMB,PowerState,Host|
ExportCSVVMs.csvNoTypeInformation
A sample result of which is shown below:
Another example where this cmdlet can be put to good use is to alleviate
a common stumbling block when attempting to VMotion virtual machines
from one ESX host to another (in case you dont use VMware regularly, to
VMotion virtual machines means to use VMware VMotion to Live
Migrate virtual machines to another physical host). There are a number
of reasons why a virtual machine might not be permitted to VMotion; one
of the most common is because it has a local CD-Rom drive attached.
The below set of commands will iterate through all virtual machines, lter
them based on whether the connection state of their CD-Rom drive is true,
and return the name of the offending virtual machine(s):
GetVM|WhereObject{$_|GetCDDrive|
WhereObject{$_.ConnectionState.Connectedeq"true"}}|
SelectObjectName
One of the great things about PowerShell is the intuitive possibility to

gradually build up a set of commands to carry out increasingly more
complex actions. This means it becomes possible to both review and
appropriately congure your VMs in a single step. In this instance, as well
5/14
11/15/2016
as retrieving the list of virtual machines where the CD-Rom is connected,

it is very simple to extend the above command to automatically
disconnect these CD-Roms, rather than carry out that task manually.
Simply use the Set-CDDrive cmdlet to change the connection status of
any connected CD-Roms which have been found:
GetVM|WhereObject{$_|GetCDDrive|
WhereObject{$_.ConnectionState.Connectedeq"true"}}|
GetCDDrive|SetCDDriveConnected$falseConfirm:$false
This is just a single example, but now that you know how to quickly gather
the data you need, you can easily target specic settings and make
appropriate congurations a snap. You can nd out more about what
cmdlets are available to adjust your VMs settings from the PowerCLI
website, as mentioned earlier.
2) Basic Capacity Information

The PowerCLI cmdlets can be used to give a quick overview of the
number of hosts and VMs that exist within the Virtual Center; it could be
useful to record these gures on a monthly basis so that the growth of the
environment can be tracked over time. How about nding the average
number of VMs per host in a cluster? Again, a useful gure to regularly
record so as to observe what consolidation ratios are being achieved and
to plan for future capacity needs, and a gure which PowerCLI can help
you nd.
In the code below, we retrieve the ESX / ESXi hosts & VMs and observe
their count; note the use of the $DefaultVIServer variable, which is
updated each time a connection is made to a vCenter.
For the average number of VMs in each cluster, we nd the total number
of ESX / ESXi hosts and VMs and perform some basic maths to arrive at a
gure. Note the use of some basic .NET [math]::round code and the
number of decimal places (1) required to format the output as desired:
#Totalnumberofhosts
$TotalVMHosts=(GetVMHost).Count
WriteHost"Thereare$TotalVMHostsHostsin$DefaultVIServer"
#Totalnumberofguests
6/14
11/15/2016
$TotalVMs=(GetVM).Count
WriteHost"Thereare$TotalVMsVirtualMachinesin
$DefaultVIServer"
#AverageVMsPerCluster
$Clusters=GetCluster
foreach($Clusterin$Clusters){
$VMHosts=GetCluster$Cluster|GetVMHost
$VMs=GetCluster$Cluster|GetVM
$AverageVMsPerCluster=[math]::round(($VMs.count/$VMHosts.cou
nt),1)
WriteHost"$Clusterhas$AverageVMsPerClusterguestsperVMware
host"
3) Rescanning for New Storage

What used to be one of the most onerous tasks for a VMware
administrator was using the vSphere Client GUI to re-scan all hosts in a
cluster for new storage after an additional SAN Lun had been provisioned.
This would require individually selecting each host within the cluster,
scanning it for new storage, and then moving on to the next host until all
were complete a process which quickly becomes frustrating.
Thankfully, in vSphere 4.0, VMware added a new option when rightclicking a cluster Rescan for Datastores. Once initiated, this task would
work through each host in the cluster and scan for new storage.
However, if you are running a VMware version prior to version 4.0 in your
environment, or maybe you want to rescan hosts in more than one cluster,
then the Get-VMHostStorage cmdlet has two parameters which youll nd
useful: -RescanAllHba and -RescanVmfs. Used in combination with the
Get-Cluster and Get-VMHosts cmdlets, Get-VMHostStorage can quickly
become very powerful; for example, the command below will rescan for
new storage on all of the hosts in Cluster 1:
7/14
11/15/2016
GetCluster'Cluster1'|GetVMHost|
GetVMHostStorageRescanAllHbaRescanVmfs
4) VMotion Virtual Machines to other Hosts

As a virtual infrastructure admin you will, from time to time, need to carry
out maintenance on a host server, whether through patching or hardware
replacement. As Ive already alluded to, VMware provide some fantastic
VMotion technology within ESX and vCenter, which enables virtual
machines to be transferred from one physical host to another with no
downtime incurred for the virtual machine. To move all VMs from one
host to another, use this simple one liner:
GetVMHostesx01|GetVM|MoveVMDestination(GetVMHostesx02)
Of course, you may not have enough resources on the target host to move
all VMs across, and consequently might wish to distribute them more
evenly across a number of hosts. Wrapping all that lovely technology into
just one elegant step, the short script below will VMotion all of the virtual
machines from one host in a cluster to random other hosts within the
same cluster.
$sourcehostname=(GetVMHost'esx01').name
$clusterhosts=GetCluster'Cluster1'|GetVMHost|
WhereObject{$_.namenotlike"$sourcehostname"}
$vms=GetVMHost$sourcehostname|GetVM
foreach($vmin$vms){
$targethost=$clusterhosts|GetRandom
MoveVMVM$vmDestination$targethost
}
First of all, the name of the source host will be stored in the variable
$sourcehostname. Then we retrieve all of the hosts within Cluster 1, drop
the source host from that list, and store the results in $clusterhosts. Next,
we retrieve all of the virtual machines on the source host, storing them in
$vms, and nally we cycle through each virtual machine, generate a
random target host and move the VM to that target host.
5) Storage VMotion Virtual Machines to a New SAN
8/14
11/15/2016
In a similar way to how the VMotion technology migrates a virtual

machine from one physical host to another, it is also possible to move the
disks for a virtual machine between datastores whilst the virtual machine
remains online this technology is known as Storage VMotion. This is
even possible between different SANs, provided the hosts are congured
to see storage on both old and new SANs and there is sufcient
bandwidth to transfer the necessary data.
Lets say you have mapped out in, a CSV le, which datastore the disks for
each virtual machine are moving to:
We can bring that data into the PowerShell session with the Import-CSV
cmdlet, and then feed it into the Get-VM and Move-VM cmdlets to
Storage VMotion those virtual machines to the new SAN.
$vms=ImportCSVC:\Scripts\SVMotion.csv
foreach($vmin$vms){
GetVM$vm.name|MoveVMDatastore$vm.targethostname
}
Note that the Import-CSV cmdlet will take the column headers in the CSV
le and enable access to them as property labels; i.e. for line 2, $vm.name
is Server01 and $vm.targetdatastore is Datastore1_NEW.
When carrying out such a SAN migration, you may wish to carry out the
work outside of normal ofce hours to take advantage of low-use periods
on the SAN, and consequently move the data quicker. So, why not create
a Windows Scheduled Task to kick off the above script and schedule it for
the required time? If you wanted to be really smart, you could use the
9/14
11/15/2016
Send-MailMessage PowerShell cmdlet to have it email you each time a

Storage VMotion completes.
6) Deploying Virtual Machines from a Template

Deploying new virtual machines is a simple task, particularly if youve
created a base template and use the Guest Customisation feature to
sysprep a new Windows virtual machine. However, even this process can
quickly become tedious if youre deploying multiple virtual machines from
the GUI.
Lets take an example where you have the requests for ve new virtual
machines provided to you in a CSV le:
The virtual machines can be easily deployed by, once again, using ImportCSV to read in the input data. Then we cycle through the virtual machines
and, for each deployment, get the template, host,datastore and
customization to use, before nally executing the New-VM cmdlet and
feeding it those various parameters to use for creating each VM:
$vms=ImportCSVC:\Scripts\NewVMs.csv
foreach($vmin$vms){
$Template=GetTemplate$vm.template
$VMHost=GetVMHost$vm.host
$Datastore=GetDatastore$vm.datastore
$OSCustomization=GetOSCustomizationSpec$vm.customization
NewVMName$vm.nameOSCustomizationSpec$OSCustomization`
Template$TemplateVMHost$VMHostDatastore$DatastoreR
unAsync
}
10/14
11/15/2016
7) Conguring vSwitches and Port Groups

Keeping the networking conguration consistent and accurate across all
ESX / ESXi hosts in a cluster is crucial. This is particularly the case for
technologies like VMotion, which requires identically congured
networking on the source and target hosts to enable virtual machines to
transfer between them. In an enterprise environment, it would be very
common to have multiple VLANs made available via multiple port groups
on different vSwitches. Consequently, when deploying a new ESX / ESXi
host into a cluster, a signicant amount of manual networking
conguration could be required, which could easily lead to mistakes being
made, and one very bored administrator.
To address this, VMware have introduced some new technology into
vSphere 4.0, known as Host Proles; however this is only available to
customers who have purchased Enterprise Plus licensing. Well known
PowerCLI community expert Alan Renouf has provided a simple
alternative solution to this problem via his blog (rather than reproduce the
script here, I recommend you take a look at his blog once youve nished
here. Ill include a link at the end of the article). This short script will
prompt the administrator for a source and target host, copy the network
conguration from the source host and apply it to the target. Simple, yet
very effective, and a great time saver; and no requirement to use Host
Proles.
8) Conguring an NTP Time Server

Another item to keep consistently congured across the ESX / ESXi hosts
is the NTP server used to keep the time. Whether setting this on a new
host or making a change across all hosts, its a snap to do it with
PowerCLI. To add an NTP server to a new host, esx01, not previously
congured use:
GetVMHostesx01|AddVMHostNtpServerNtpServerntpservername
Or to rst of all clear existing NTP server(s) then set the new one:
GetVMHostesx01|RemoveVMHostNtpServer`
11/14
11/15/2016
NtpServer(GetVMHostesx01|GetVMHostNtpServer)
GetVMHostesx01|AddVMHostNtpServerNtpServerntpservername
9) Patching Via VMware Update Manager

As mentioned at the beginning of the article, there is an additional set of
commands which can be used in conjunction with VMware Update
Manager to assist with the automation of patching ESX / ESXi hosts or
VMs. When planning a patch deployment, it might be necessary to provide
information up front to management regarding the list of patches which
you intend to install. Whilst VMware Update Manager has a GUI which is
useful for most tasks, it is difcult to extract this information out from the
GUI and into a distributable format.
The code below will nd the compliance status of a host, as scanned
against a baseline, and then export a list of patches required by that host
out to a CSV le:
$ComplianceStatus=GetComplianceEntity'esx01'Detailed
$ComplianceStatus.NotCompliantPatches|
SelectObjectName,IDByVendor,Description,`
@{n='Product'e={$_.product|
SelectObjectexpandpropertyVersion}},ReleaseDate|
ExportCsvpatches.csvNoTypeInformation
Or how about bringing any newly installed ESX / ESXi host immediately
up-to-date with the current standard patch baseline? Easy.
Retrieve the required baseline:
$Baseline=GetBaseline"CurrentESXBaseline"
Attach the baseline to the required ESX / ESXi host:

$Baseline|AttachBaselineEntityesx01
Scan the host to determine required patches:

ScanInventoryEntityesx01
Remediate the host against the required baseline:

12/14
11/15/2016
$Baseline|RemediateInventoryEntityesx01Confirm:$false
These commands could all be added to a short script to be run at the end
of a build process, to ensure that all newly deployed hosts are at the
required patch level.
10) Schedule the vCheck Reporting Script to Run Daily

The previously mentioned PowerCLI community expert, Alan Renouf, has
put together an amazing and, very generously, completely free PowerShell
reporting script, which can be run against a vCenter environment and
report back on many common issues and best practises. This report is
known as vCheck, and is available from Alans Virtu-Al.net website. It is a
great way to be proactive and nd issues with the infrastructure before
they become serious.
Common issues that will be found include snapshots which are over a
specied number of days old, VMs with no VMware Tools installed, and
datastores with less than a specied amount of free space available. It is
highly recommended to schedule this report to run against your vCenter
and have it email you with the results on a daily basis you will most
likely nd issues you did not even know you had!
Summary
VMware environments of any size, small or large, can benet greatly from
automation. This article has introduced you to some of these possibilities
and how you might use them to make your systems run better, in a more
consistent fashion. The beauty of this is twofold: youll nd it signicantly
easier to be aware of the status of all your virtual environments, and youll
have more time to spend on the projects that you never get around to.
Not only will you be proactive, but youll also have more time to feel selfsatised about it. PowerCLI is intuitive to use, and it is incredibly simple to
very quickly get real results with it I urge you to give it a try, if you
havent already done so!
Resources
13/14
11/15/2016
VMware Tools:
ESX / ESXi
vSphere PowerCLI
vSphere CLI
vSphere SDK for Perl
Alan Renoufs vSwitch Script
Alan Renoufs vCheck
This article was commissioned by Red Gate Software, engineers of

ingeniously simple tools for optimizing your Exchange email
environment.
Learn more about Exchange Server Archiver and PST Importer.
For more articles like this, sign up to the fortnightly Simple-Talk

newsletter.
Tags: BI, Jonathan Medd, Sysadmin, Virtualization
2005 - 2016 Red Gate Software Ltd
14/14

10 Steps To Kick-Start Your VMware Automation With PowerCLI - Simple Talk

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

10 Steps To Kick-Start Your VMware Automation With PowerCLI - Simple Talk

Transféré par

Droits d'auteur :

Formats disponibles

11/15/2016

A technical journal and community hub from Redgate

10 Steps to Kick-Start Your VMware

.NET Framework 2.0 SP1

The nal step to getting started with PowerCLI is to make a connection to

or a host, if directly conguring a host:

10 Steps to Kick Start Automation

1) Reviewing and Conguring Virtual Machines

A sample result of which is shown below:

One of the great things about PowerShell is the intuitive possibility to

as retrieving the list of virtual machines where the CD-Rom is connected,

2) Basic Capacity Information

3) Rescanning for New Storage

4) VMotion Virtual Machines to other Hosts

5) Storage VMotion Virtual Machines to a New SAN

In a similar way to how the VMotion technology migrates a virtual

Send-MailMessage PowerShell cmdlet to have it email you each time a

6) Deploying Virtual Machines from a Template

7) Conguring vSwitches and Port Groups

8) Conguring an NTP Time Server

9) Patching Via VMware Update Manager

Attach the baseline to the required ESX / ESXi host:

Scan the host to determine required patches:

Remediate the host against the required baseline:

10) Schedule the vCheck Reporting Script to Run Daily

This article was commissioned by Red Gate Software, engineers of

For more articles like this, sign up to the fortnightly Simple-Talk

2005 - 2016 Red Gate Software Ltd

Vous aimerez peut-être aussi