Online Training – Automating vSphere with the VIX API from Eric Sloof NTPRO.NL on Vimeo.

I can’t wait to try this out, although I think I’m going to have to do a little Visual Basic study first.

The following enhancements have been made to ESX (from the release notes):-

VMware View 4.0 support – This release adds support for VMware View 4.0, a solution built specifically for delivering desktops as a managed service from the protocol to the platform.

Windows 7 and Windows 2008 R2 support –This release adds support for 32-bit and 64-bit versions of Windows 7 as well as 64-bit Windows 2008 R2 as guest OS platforms. In addition, the vSphere Client is now supported and can be installed on a Windows 7 platform. For a complete list of supported guest operating systems with this release, see the VMware Compatibility Guide.

Enhanced Clustering Support for Microsoft Windows – Microsoft Cluster Server (MSCS) for Windows 2000 and 2003 and Windows Server 2008 Failover Clustering is now supported on an VMware High Availability (HA) and Dynamic Resource Scheduler (DRS) cluster in a limited configuration. HA and DRS functionality can be effectively disabled for individual MSCS virtual machines as opposed to disabling HA and DRS on the entire ESX/ESXi host. Refer to the Setup for Failover Clustering and Microsoft Cluster Service guide for additional configuration guidelines.

Enhanced VMware Paravirtualized SCSI Support – Support for boot disk devices attached to a Paravirtualized SCSI ( PVSCSI) adapter has been added for Windows 2003 and 2008 guest operating systems. Floppy disk images are also available containing the driver for use during the Windows installation by selecting F6 to install additional drivers during setup. Floppy images can be found in the /vmimages/floppies/ folder.

Improved vNetwork Distributed Switch Performance – Several performance and usability issues have been resolved resulting in the following:

• Improved performance when making configuration changes to a vNetwork Distributed Switch (vDS) instance when the ESX/ESXi host is under a heavy load
• Improved performance when adding or removing an ESX/ESXi host to or from a vDS instance

Increase in vCPU per Core Limit – The limit on vCPUs per core has been increased from 20 to 25. This change raises the supported limit only. It does not include any additional performance optimizations. Raising the limit allows users more flexibility to configure systems based on specific workloads and to get the most advantage from increasingly faster processors. The achievable number of vCPUs per core depends on the workload and specifics of the hardware. For more information see the Performance Best Practices for VMware vSphere 4.0 guide.

Enablement of Intel Xeon Processor 3400 Series – Support for the Xeon processor 3400 series has been added. For a complete list of supported third party hardware and devices, see the VMware Compatibility Guide.

vCenter 4.0 has also been updated, and now has full compatibility with Windows 7 x86 and x64 versions. Saving the various hacks that were necessary to get it working.

Also, the PowerCLI has been updated, and can be found here. There are 68 new CMDLETS, which Alan Renouf does a great job of explaining. I’m especially looking forward to trying out Get\Set-CustomAttribute (no more manipulation of the View object), Move-VMTemplate (no more converting templates to machines), and Get\Set-VMQuestion (for those times when the datastores run out of space for the REDO files necessitated by Non-Persistent disks).

I’m looking forward to investigating the new PowerCLI functionality, and I’m also looking forward to not needing to  manually customise the dozen or so Windows 7 guests I’m deploying next week!

vAlarm is a Windows® based application which monitors alarms generated by VMware® vCenter.

The product is designed to be installed on an administrators PC, and provides automated monitoring of vCenter alarms without needing to be logged into a full VI Client console.

The software automatically communicates with a vCenter server on a user configurable schedule, and notifies any active alarms via a popup information bubble in the notification area of a users desktop.

The option to show details of all active alarms displays an information dialogue which lists individual alarms with detailed descriptions.

The software supports VMware vCenter 2.5 & 4.0.

It’s turned out to be quite handy, as it’s making me far more conscious of alarms. It might even encourage me to modify the default set of alarms – I’m generally not interested in guests going into the red because of CPU or memory due to the nature of the way they’re used, but I do need to know when hosts and datastores are running close to capacity.

The system tray application pops up a bubble, even when there are no alarms, which isn’t strictly necessary, and it might be nice to be able to collate notifications from more than one vCenter Server (I’m currently watching over two); but these are minor quibbles about a free product.

You can download vAlarm from XtraVirt (free registration required).

This script loops through the list of vCenter servers, and gets their version and build info, as well as the version and build info for it’s connected hosts.

# Script to connect to a list of vCenter Servers, and get their version numbers, as well as the version numbers of their hosts
# Ben Neise
# 02/10/09
 
# Array of vCenter Servers
$arrVCenterServers = @("server1","server2","server3")
 
# Create empty arrays for the results
$arrTableVCs = @()
$arrTableHosts = @()
 
# Loop through the array of vCenter servers specified above
ForEach ($strVCenterServer in $arrVCenterServers){
	# Connect to the VC
	$objVCenterServer = Connect-VIServer $strVCenterServer
	# Version info about the VC you are connected to
	$viewVCenterServer = Get-View serviceinstance
	# Add custom attributes to each VC objects for version and build
	$objVCenterServer | Add-Member -Name Version -type noteproperty -value ($viewVCenterServer.content.about.Version) -Force
	$objVCenterServer | Add-Member -Name Build -type noteproperty -value ($viewVCenterServer.content.about.Build) -Force
	# Add the VC object to the results array
	$arrTableVCs += $objVCenterServer
	# When connected to loop through the hosts managed by the VC
	ForEach ($objHost in (Get-VMhost | Sort-Object)){
		# Get the view for the current host
		$viewHost = $objHost | Get-View
		# Add custom attributes to the host object for VC server, Host and Version
		$objHost | Add-Member -Name VCServer -type noteproperty -value $objVCenterServer.Name -Force
		$objHost | Add-Member -Name Host -type noteproperty -value $viewHost.Name -Force
		$objHost | Add-Member -Name Version -type noteproperty -value $viewHost.Config.Product.Version -Force
		# Add the host object to the results array
		$arrTableHosts += $objHost
	}
	# Disconnect from the VC server
	Disconnect-VIServer -Confirm:$False
}
# Output the VC results (can be modified to output to a CSV with Export-CSV)
$arrTableVCs | Select-Object Name, Version, Build | Sort-Object Name
 
# Output the Host results (can be modified to output to a CSV with Export-CSV)
$arrTableHosts | Select-Object VCServer, Host, Version, Build | Format-Table
 
# End of script

# Sets up virtual port groups on all hosts connected to a specific vCenter Server
 
# Name of vCenter Server
$strVCenterServer = "your.vCenter.Server"
 
# VLANs and associated VPGs
$ArrVLANs = @{
	"123" = "Admin";
	"456" = "GPO";
	"789" = "NAG";
}
 
# Connect to the vCenter Server
Connect-VIserver $strVCenterServer
 
# Loop through the VLAN/VPG pairs
ForEach($objVLAN in ($ArrVLANs.Keys | Sort-Object)){
	# Loop through the hosts
	ForEach ($objHost in (Get-VMHost | Sort-Object)){
		# Create the VPG with the VLAN as specified in the array above, on the switch called "VMSwitch" on the current host
		# Remove the "-WhatIf" tag from the end of the following line to "arm" the script
		New-VirtualPortGroup -Name $strNewVPG -VirtualSwitch (Get-Virtualswitch -VMHost $objHost | Where-Object { $_.Name -match "VMswitch" }) -VLanId $strNewVlanTag -WhatIf
		# Write what we've just done to screen
		Write-Host "Adding Virtual Port Group" $ArrVLANs[$objVLAN] "with VLAN Tag" $objVLAN "to" $objHost
	}
}
# Disconnect the session from the host
Disconnect-VIServer -Confirm:$False

Although this isn’t a complicated script, it was the first time I’ve used hash tables (thanks to PowerShell.Com’s excellent page), so I thought I’d share.

VirtualGeek had an interesting article on thin-provisioning in vSphere 4, and whether this should be done at the VM level, or at the array level. As well as containing a good description of the different disk types (Thick, Thin & Eagerzeroedthick), there was a brief mention of using TP disks in VI 3.5. This was the first time I’d heard of this, and despite it’s unsupported nature, it deserved some consideration. We’re still using VI 3.5, and disk space is probably our number one capacity constraint; the potential opportunity to reduce our disk-footprint without investing in any new hardware or software was too good to pass up.

I soon discovered that we already used TP disks in a very limited way. One of the options in vCenter’s Clone to Template operation allows the creation of a compact template, and we had been using this to reduce the amount of space used by templates. Templates created in this manner use TP disks, and if you convert that template to a machine, the machine inherits the TP disk. However VMs deployed from the template are created with normal (thick) disks. If you’re curious to see if you’ve got any existing TP machines, Eric Gray wrote a PowerShell script to find existing thin provisioned disks.

After only a little more digging, my dream of being lauded for increasing our free space overnight came to an end. In an article on Virtual Future, Sven Huisman wrote:

Apparently, when you move a VM with a thinprovisioned disk from vCenter server, it converts to a thick-disk. This is because thinprovisioned disks is not integrated with vCenter server yet.

Also, when you deploy from a template with a thinprovisioned disk, the new VM will get a thick-disk.

I imagine this is what they mean by “unsupported”, and this is why the TP functionality in VI 3.5 is largely undocumented.

This changes the conversion process from a one-off time-consuming action to something that would need to be done on an ongoing basis. I think we’ll just have to wait until we get the chance to upgrade to vSphere 4.

Video from vCritical showing installation and GUI on the new vCenter.

Remotely accessing ESX Guests on an (emulated) portable device.  If only I could convince work to get me a BlackBerry it would free me from my desk.

The only problem being; I’m not entirely sure where I would go instead.

While I was (and I still am) impressed by VMware’s hypervisor based virtualisation, there were a few things that started to grate with such an otherwise excellent product:-

• Performing repetitive tasks – for example setting a group of virtual hard-drives to non-persistent – using the vSphere Client GUI was time-consuming (and RSI inducing!).
• There was also no real way of extracting information from vCenter in any structured way. For example, if I wanted to know how many of our Microsoft Windows XP guests had over 512MB RAM allocated to them, they had to be counted manually.

I had a look into running scripts on the host, and toyed with the Remote CLI Appliance, but it was the VMware PowerCLI that unlocked the functionality I’d been looking for.

VMware PowerCLI (formerly VI Toolkit for Windows)  utilises Windows PowerShell to provide a command-line driven interface for your virtual infrastructure. This can dramatically reduce the amount of time taken to perform almost all batch-style tasks and also enables some pretty advanced reporting functionality.

This is nowhere near a proper introduction in how to use PowerShell, but should give enough information to get you started, and hopefully make you want to find out more.

PowerCLI pre-requisites

Powershell is included in Windows 7, and Server 2008, but if it’s not included in your version of Windows, you’ll need to  download and install the appropriate version of Windows PowerShell for your operating system.

Then you need to download and install VMware vSphere PowerCLI (registration required).

If you’re running  PowerShell for the first time you need to change the default execution policy.  To do this:

1. As a user with local Administrator rights, run Windows PowerShell  (on machines with UAC, right-click and Run as Administrator)
2. In that window – run the command

Set-ExecutionPolicy - ExecutionPolicy RemoteSigned

This allows you to run local scripts which have not been signed with a digital signature (which will almost certainly include the scripts you’re using to learn). Scripts from remote sources will still require signing.

Security considerations

The PowerShell security model is designed to address some of the  failures of VBScript – a common virus attack vector. PowerShell scripts (which have a PS1 suffix) do not run by default when invoked in Windows.  Also, as noted above, the default execution policy is not to run unsigned scripts. In order to run a script, you need to modify the execution policy, and then run the script name from the command line. This helps to prevent them from being launched by accident.

In vSphere, users running PowerCLI scripts  have the same permissions as they would get if they logged into vSphere Client. However, as with all scripting languages,  when modifications can be  made easier and faster, the potential impact of mistakes is made greater. PowerShell includes specific measures to alleviate risk, and it’s worth being familiar with this functionality before trying anything more complex.

PowerShell fundamentals

PowerShell works using cmdlets. These are typically fairly descriptive, and great care has been taken to make them work in a consistent and logical way. Most cmdlets follow the format verb-noun, with modifiers for the target of the action, and any cmdlet specific options. They are not case sensitive.

The downside of the commands being so descriptive is that they are sometimes quite long. In order to alleviate this PowerShell allows Aliases to be created. Most common Windows Shell commands already exist in PowerShell as aliases. For example CD, DIR, CLS & REN all work as expected. I find these quite useful when working interactively (entering commands at the prompt for immediate execution), but I tend to avoid them in scripts for the sake of consistency and clarity.

When launching scripts, you need to use absolute paths. For example, if you want to launch the script C:\Scripts\ExampleScript.ps1, when you’re in C:\Scripts you would either need to enter the whole path, or use  ./ExampleScript.ps1.

In order to use PowerShell, you need to import the VI commands using

Add-PSSnapin VMware.VimAutomation.Core

Running the VMware vSphere PowerCLI shortcut created when you install the application does this on launch.

Running the standard PowerShell shortcut does not.

You can however add it to your PowerShell profile, which will enable it in all PowerShell sessions, no matter which shortcut you use to launch them.

PowerShell is object-oriented, meaning that the information returned from commands can be easily used as the input for another command.

If you want to put comments into your scripts, PowerShell ignores anything after the #symbol.

Some simple Cmdlets

Here are a couple of commands to get you started. Open up the PowerCLI command line using the VMware vSphere PowerCLI shortcut, then enter them as shown.

Get-Help

Can display help on the various cmdlets. Running this as above shows the syntax for getting help.

Get-Command

Use to find out all the commands containing certain keywords. For example…

Get-Command *-VM

…uses the wildcard character (*) to show all commands that end with VM, this shows all the  cmdlets that can be used to operate on Virtual Machines. Let’s try a simple one…

Get-VM

You should now get an error message saying “You are not currently connected to any servers. Please connect first using Connect-VIServer or one of its aliases.”. Let’s do that…

Connect-VIServer Name_of_your_vCenter_Server

This uses your current windows credentials to connects to the specified server.  You need to do this before you run any VMware specific PowerShell commands. Now try this again…

Get-VM

You should now be looking at a list of virtual machines managed by your vCenter server.  You can reduce the scope by adding switches, for example…

Get-VM –Name A*

…gets all machines with names starting “A”. For more information, try

Get-Help Get-VM -Detailed

Variables in PowerShell are always preceded by a $ symbol. You can set a variable to the result of any kind of PowerShell command, for example, you can store the results of a Get-VM in a variable…

$objVMs = Get-VM

then use that variable any time you need it, typing

$objVMs

Will display the virtual machine objects stored in the variable. This variable is a collection of objects, each object representing a virtual machine, so we can run more commands against this variable:

Get-VMGuest -VM $objVMs

This lists the State, IP Address and guest OS of all your machine objects.

Instead of using variables for commands like this, you can also pipe the result of one command, straight into another. The equivalent of the above command, using pipes rather than variables is

Get-VM | Get-VMGuest

The objects output byt he first command are piped straight into the second command. Pipes are used extensively in PowerShell, and many cmdlets can be linked together using pipes. This means you can run some complex commands in PowerShell at the command prompt in one line, rather than resorting to writing a script.

Have a  play around with these commands in your test environment before moving onto the next section. As long as you’re using Get- based commands, (rather than Set- or Remove-) you shouldn’t make any changes, but append -WhatIf and/or -Confirm to the end of your Cmdlets if you’re feeling extra-cautious.

Example scripts

Like batch files, PowerShell scripts are simply collections of commands linked together into a text file.

Here are a couple of example scripts, showing what can be done.  Copy into notepad, and save with a PS1 extension. You should run Connect-VIServer interactively before running any of the scripts (or add it as the first line to the script file).

Get information about a specific machine

$strVm = Read-Host "Please enter the VM name"
$vm = Get-VM -Name $strVm
if ($vm.PowerState -eq "PoweredOn") {
$event = Get-VIEvent -Entity $vm | Where-Object {$_.fullFormattedMessage -like "Task: Power on Virtual Machine"}
$VM.Name
$VM.PowerState
(Get-VMGuest -VM $VM).IPAddress[0]
if ($event -eq $null) { Set-Variable -Name user -Value "N/A" } else { Set-Variable -Name user -Value $event[0].username }
$strMessageText = "Machine: " + $VM.Name + "`n" + "Power State: " + $VM.PowerState + "`n" + "IP Address: " + (Get-VMGuest -VM $VM).IPAddress[0] + "`n" + "Switched on by: " + $user
$strMessageText
}
else
{Write-Host "Machine not powered on"}

This script asks the user for a machine name (using Read-Host), then converts that string to a computer object, then (assuming the machine is switched on and VMware Tools is running), displays the DNS name, IP address and the username of the last user to power on the machine (as shown in the machine’s Event Log). The `n is a carriage return.

Get All Windows XP Machines with more than 2Gb of RAM

ForEach ($strMachine in (get-vm | Where-Object {$_.MemoryMB -gt "2000"})){
Get-VMGuest -VM $strMachine | Where-Object {$_.OSFullName -like "Microsoft Windows XP Professional*"} | Select-Object VMName, IPAddress
}

This script could easily be modified and used as a component to make modifications on machines fulfilling certain criteria.

What else can you do?

Almost anything that can be done in the GUI can be done in PowerShell.  Machines can be deployed, customized, switched on, migrated between hosts and resource pools etc. Or you could get the last time a machine was switched on, and by whom.

You can also use PowerCLI to report on the status of guests and hosts. Check out Alan Renouf’s excellent PowerCLI Daily Report, or Hugo Peeter’s script to track free space in your datastores.

One drawback of the API is that performance of cmdlets (especially Get-VM) is quite slow.  Hopefully this will be addressed in future versions.

Further resources

There are many tools, example scripts and on-line resources available. Your first stop for help should be the VMware vSphere PowerCLI Community. I also recommend you keep Alan Renouf’s PowerCLI reference card close-to-hand when you’re just starting out.