• Login
• Become a member
• RSS
• Part of the TechTarget network

Rick Vanover

Scripting is one of the sharpest tools in a virtualization administrator's toolbox. VMware now offers increased support for PowerShell scripting via the VMware Infrastructure Toolkit. In this tip, I'll show you how to power on a virtual machine, update VMware Tools and more with basic PowerShell scripts. You'll get an overview of PowerShell capabilities for VMware, as well as good resources to script other tasks in your environment as you see fit.

VMware PowerShell resources
Before you go too far out on your own, chances are someone has done some of the work for you – you just have to know where to look. So it's a good idea to include the VMware PowerShell blog as one of your frequent destinations. There you can find a wealth of script samples as well as good information on how new tasks that can be accomplished with the ever-changing world of VMware products. Also from here, you can download the VMware Infrastructure Toolkit (VI Toolkit) for installation. This requires a current Windows PowerShell installation.

Once you install the VI Toolkit, your first task should be to read through the VI Toolkit Administrators Guide, which is a PDF file that's included with the download. From there you can jump into the following sample scripts to get a feel for how the interface works. Then you can experiment with creating your own scripts.

1. Power on a virtual machine
A script that powers on a virtual machine (VM) may not appear that exciting, but it's a good starting point. The VI Toolkit has a wealth of commands available for basic VM operations. Powering on a VM is done with the Start-VM command, and the script is quite simple for a basic startup task. The following script powers on a VM by name:

Start-VM -VM VM-TESTSERVER1

This task will execute immediately as entered. While it is executing, progress is simultaneously displayed in the VI Toolkit and in the familiar scrolling log in the VMware Infrastructure Client. The figure below shows the text-based progress of the power-on operation.

Click to enlarge.

This basic command has a lot of potential because it has what I like to call "wildcard functionality." For example, you can power on an entire class of systems at once. The following command would power on every VM with the string "testserver."

Start-VM -VM *TESTSERVER*

Be careful not to create a "boot storm" on your storage system, as many systems can be executed with this command.

2. Update VMware Tools
 

Keeping VMware Tools up-to-date on all your guest VMs is a task that frequently challenges and ends up getting away from administrators. The VI Toolkit allows administrators to pass the automatic update command to guests. For Windows guests, this will cause a reboot as Windows guests need to reboot to complete the installation, so use this command with caution for your environment.

The following example would update VMware Tools on all servers of the following name type:

Update-Tools -VM *TESTSERVER*

This command does not transfer any security credentials or additional configuration to the guest VM. For a VM that has auto-run disabled, the virtual CD-ROM may not launch and run the upgrade of VMware Tools. Likewise, a virtual CD-ROM device is required to be part of a VM's inventory to allow this type of upgrade to proceed.

3. Find out which VMs are on local disk
For most VMware VI3 implementations, VMs should be kept on shared storage in order to utilize features such as High Availability and VMotion. Inevitably, though, some VMs end up on local storage. The following script enumerates all VMs on local storage.

Get-VM –Datastore Servername*

The above script assumes that local VMFS volumes, if present, use the default naming system. By having an organized LUN nomenclature, this query can be easy to run as a wildcard. Further, you can export the results to a text file with a simple tweak to the script, as seen below.

 

Get-VM –Datastore Servername* > C:\localstorageVMs.txt

4. Configure NTP time server for hosts
Consistent configuration of the host is critical to a successful VI3 implementation. One area that can cause all kinds of havoc is the local time configuration of the ESX host. Problems due to time configuration issues can include VMotion failures, VMware High Availability failures and complications with server connection to the vCenter server statuses. Further, it is a good idea to have all systems point to an authoritative time source in your organization. A native Network Time Protocol (NTP) client is on the host, which was an update released with ESX 3.5. If you haven't been using it, you should. The following script will configure the host to use an NTP server by DNS name.

Add-VMHostNtpServer -NTPServer ntp.server.com -VMhost server.dns.name

Like other areas of the VI Toolkit, you can use wildcards here as well. In the host name (server.dns.name), you could put in a wildcard such as the entry below:

Add-VMHostNtpServer -NTPServer ntp.server.com -VMhost *server*.dns.name

You need to be careful with this command, as you can pass on a configuration that may already have been made or sent as an update to a collection of hosts – which could include a live VM workload.

5. Respect the permissions model
By default, the VI Toolkit will interact with the specified ESX host or VMware vCenter Server as defined by the current logged-in Windows credentials. Once the VI Toolkit is loaded, the PowerShell console asks you to specify which server to connect to.

Click to enlarge.

From the initial screen, you can launch the Connect-VIServer command interactively or pass all options to connect directly from one line. The script below would connect to the vCenter server (rwv-vi3.rewvdev.intra) with a username and password passed for the connection:

Connect-VIServer -Server rwv-vi3.rwvdev.intra -User vmconfigurator -Password Sc3!pt

Once you pass the credentials, the server is listed as a connection. The VI3 permission model can be set to perform certain tasks for the overall environment and/or as they apply to the VI Toolkit. The permissions would be set in the VI Client and extend to the VI Toolkit.

Be careful not to work with the VI Toolkit as root or an administrator-level account frequently, however; the wildcards make it possible for one errant script to shut down every virtual machine in the environment.

One safeguard that can be used with all VI Toolkit scripts is the confirm option. This will force each action item to pass an interactive prompt before proceeding with the script. The two scripts below show me searching for the name of the VM, then powering it on:

Get-VM *Tes* Start-VM VM-TestServer4 –Confirm

The interactive nature of the confirm parameter is shown below.

Click to enlarge.

 

Rick Vanover (MCTS, MCSA) is a systems administrator for Belron US in Columbus, Ohio. Vanover has more than 12 years of IT experience. His areas of interest include virtualization, Windows-based server administration and system hardware.

 

Join the conversationComment

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

All Rights Reserved,Copyright 2007 - 2013, TechTarget