Home > Blogs > VMware PowerCLI Blog > Monthly Archives: May 2009

Monthly Archives: May 2009

Don’t forget – PowerCLI Webinar next Wednesday at 9:00 a.m. PDT

As I announced a few weeks ago, I’ll be giving a webinar on Wednesday, June 3 2009 to cover the most popular PowerCLI topics as determined on our voting site.

The topics I’ll cover are:

  1. Analyzing log data.
  2. Reporting.
  3. Advanced ESX host configuration.
  4. Performance analysis.
  5. A brief mention of the tools for provisioning ESXi.

Be sure to mark your calendars!

Moving custom fields from one vCenter to another.

If you’re looking at upgrading to vSphere, one thing that may come in handy is an easy and flexible way to move custom fields from your old vCenter to your new one. With PowerCLI this is quite easy… except for one thing: there is no Get-CustomField cmdlet! The why is a long story but it turns out it’s pretty easy to write just such a thing. In fact here it is:

function Get-CustomField {
 foreach ($cf in $item.CustomFields) {
  if ($cf.Value) {
   $field = "" | Select Key, Value, EntityName
   $field.Key  = $cf.Key
   $field.Value  = $cf.Value
   $field.EntityName = $item.Name
   Write-Output $field

Not too hard at all, really. So how do we use this? One nice feature of PowerCLI that often gets overlooked is its ability to connect to multiple vCenters at once and manage them all. We can take advantage of this to connect to both our old vCenter and our new one, and move the values directly between them. The way this works is to store the output of Connect-VIServer in a variable, then pass this variable to later cmdlets to specify the server you want to manage. For example:

$server1 = Connect-VIServer vcserver1
$server2 = Connect-VIServer vcserver2

This next bit of code will take all custom fields on all VMs in vcserver1 and transfer them to vcserver2. This assumes the VMs already exist in both locations.

$fields = Get-VM -server $server1 | Foreach { Get-CustomField $_ }
$vms = Get-VM -server $server2
foreach ($field in $fields) {
 $vm = $vms | Where { $_.Name -eq $field.EntityName }
 Set-CustomField -Entity $vm -Name $field.Key -Value $field.Value

That’s really all there is to it. If you need to transfer custom fields on more than just VMs, say maybe you also have fields on ESX hosts, you can use a more general bit of code that will do this for all types of objects. I’ve added that example to my script repository and you can download it here.

PowerCLI is official! What’s new?

As you’ve probably seen by now,VMware vSphere was launched late last night and people all over the world are busily downloading it. If you want full details on the release the best place to find it is this excellent blog post by Eric Siebert.

At the same time, we’ve also released PowerCLI 4.0, which is the successor to VI Toolkit 1.5.

The mathematically astute amongst you may have noticed that the version number jumped from VI Toolkit 1.5 all the way to PowerCLI 4.0. Does that mean there were huge changes between 1.5 and 4.0? Not really. The numbering was changed to be in line with the version of vSphere that is released on the same day. In the past there had been a lot of confusion around what version numbers were needed, especially since ESX 3.0 was released at the same time as VirtualCenter 2.0, and later ESX 3.5 was paired with VirtualCenter 2.5. To simplify things, many of our products have begun to use the same version number, 4.0. This will also be true going forward.

Does that mean that PowerCLI 4.0 only works with vSphere 4.0? Not at all, in fact you can use PowerCLI to manage ESX and VC all the way back to 3.0 and 2.0, respectively (see how confusing that is?) Best of all, the code you wrote for managing ESX 3.0 or 3.5 will most likely work on vSphere with no modification, and you can use it to manage and automate a mixed environment of all these versions.

So what is actually new? It’s easier to describe if I share a bit of backstory. Originally there was not going to be a VI Toolkit 1.5, all of the planning we did assumed these features would be shipped with vSphere. Because PowerCLI finished development well before vSphere was ready, we decided to remove a few vSphere-specific features and release the rest of them as VI Toolkit 1.5. We kept the PowerCLI release in reserve, waiting for the big day. In the meantime we’ve been hard at work on our next feat of engineering wonder, PowerCLI 4.0 U1, which will arrive later this year.

To put it another way,

PowerCLI 4.0 = VI Toolkit 1.5 + Bug Fixes + Host Profile Cmdlets

Host profiles is a nice new feature added in vSphere that helps in large-scale provisioning and configuration auditing of ESX servers. Yavor Boychev from the PowerCLI team even put together a nice video that explains when, why and how to use the feature.

Managing host profiles with vSpherePowerCLI! from Yavor Boychev.

If you’re looking to get started right away, Hugo has a terrific Quick Start Guide on his blog.

As always, the best part about PowerCLI is our strong community, which continues to grow stronger every day. Hope to see you there.

PowerShell at tomorrow’s Wisconsin VMware Users Group

Steven Murawski and Scott Herold will be talking PowerShell and PowerCLI tomorrow at the Wisconsin VMware Users Group and it should be quite an interesting talk. You can find all the details on Steven’s blog. A recording will also be available after the fact just in case you’re not able to make it.

VI Toolkit Demos at VMworld Europe 2009 (Part 2 of 2: UI Automation)

We did two live demos as part of VI Toolkit’s breakout session at VMworld Europe 2009. A while ago, I made a post about the network monitoring demo. As LucD politely reminded me : ) it’s time to finish the job with a post on the second demo. In it, PowerShell scripts were sending mouse and button clicks to a virtual machine’s guest OS to automate installer which otherwise does not support unattended installation…


Every once in a while I find myself in a situation where I can save tons of work with a very simple UI automation. In this specific case, I’m upgrading the VMware Tools on my VMs. The Update-Tools cmdlet is the right tool for the job. There’s a small problem in my case though…


The new version of VMware Tools I’m installing is still a beta and hasn’t passed Microsoft’s driver quality tests. So when Update-Tools runs the installer, Windows pops “unsigned driver” confirmation dialog and blocks the installation. In result, Update-Tools blocks on the first VM. That’s where UI automation comes into play. I need a script which goes inside the VM’s guest OS and clicks on the confirmation button.


Windows Automation Snapin for PowerShell (or WASP) is a set of cmdlets for UI interaction. UI interaction includes stuff like finding windows and controls and sending them mouse clicks, keyboard input, etc. Sounds like the right tool for my task. I’ll need to run it not on my machine but inside each individual VM. VI Toolkit’s cmdlet for in-guest execution is Invoke-VMScript.


Finally, below is the script. Two notes:

       You need to be connected before you run it.

       For simplicity’s sake (this was a VMworld demo), the script only operates on a single machine. Extending it to work on a set of VMs is pretty straightforward.



Note: In a real life scenario, you may need to include a step for installing WASP. This includes copying WASP to the VM and invoking WASP’s Instal.ps1 script.

Icomasoft PowerScripter reaches version 1.5

If you managed to make it to VMworld Europe this year, you may have seen me talking about VI Toolkit, along with my colleague Andrey Anastasov and also Dennis Zimmer, CTO of Icomasoft. Icomasoft has a really cool product that allows you to automate using PowerCLI / VI Toolkit from directly inside VMware’s VI Client, as opposed to using a separate command window. A lot of people really appreciate the added structure and control this gives. Not only that, but PowerScripter also gives you integrated scheduling, something that can be quite tricky to get right.


Icomasoft’s PowerScripter reached version 1.5 recently, and adds experimental support for vSphere 4 as well as enhanced reporting capabilities that let you filter, sort, search and export to Excel. Check out all the details on Icomasoft’s site.

Now shipping: Managing VMware Infrastructure with Windows PowerShell

Just a short note to all you VI Toolkit / PowerCLI users out there that Hal Rottenberg’s book, Managing VMware Infrastructure with Windows PowerShell is now shipping, order your copy today!

Hal’s book is full of great tips, tricks and useful samples that will help you learn and use PowerCLI to manage and automate your virtual infrastructure. In fact you can download all those samples right now over at the publisher’s website.

And also, congratulations to Hal, all the hard work has finally paid off!

New stuff in the VI Toolkit Extensions: Part 1, Routing

One nice new addition to ESX 4 is the ability to manage the complete routing table through the API, something that you had to do through the service console in previous releases.

So, how does PowerCLI help with automating all of this? Well, not much, really, PowerCLI doesn’t have any cmdlets related to routing. But this wouldn’t be a very interesting blog post if that was the end of the story. The nice thing about PowerCLI is that it gives you full access to VMware’s extremely powerful platform, which makes it easy to fill in any missing pieces we haven’t gotten to yet.

We have such a thing in the form of the VI Toolkit Community Extensions. One of the recent additions to the extensions is a set of commands that give you total control over ESX routing, and in a way that is compatible with all of PowerCLI’s cmdlets.

The new functions are as follows:


This stuff will look familiar to anyone who has used our cmdlets. If you’ve used our cmdlets before, chances are these will work the way you expect them to without a great deal of additional learning. Once you load the extensions you can run help on any of these function names and get a listing of the options they support.

Below is a quick run-down on how this stuff works. The first and easiest thing to do is to see what routes you have. I have an ESX 4 host with an IP address of The key thing to note is that Get-TkeVMHostRoute requires a VMHost argument, and also allows you to pipe it in. To get a listing of its routes I run:

Get-VMHost | Get-TkeVMHostRoute

Here’s some sample output:


With ESX 4 there are 3 types of routes, host routes which apply to the host, console routes, which apply to the service console (you won’t have these if you use ESXi) and the routing table. Above you can see that I have a host route and 3 entries in my routing table, and that my default route is

Let’s see what adding and removing routing table entries looks like. Let’s suppose I can use to reach the network. Here’s how to do it:

Get-VMHost |
 New-TkeVMHostRoute -TableRoute -Network -PrefixLength 16 `

Pretty simple, really. Here are the results of that.


New-TkeVMHostRoute can handle all 3 types of routes. Run help New-TkeVMHostRoute to learn more about it.

To remove routes from the routing table, all you do is pipe a route into Remove-TkeVMHostRoute, like this:

Get-VMHost | Get-TkeVMHostRoute |
 Where { $_.Network -eq "" } | Remove-TkeVMHostRoute


Something that’s not immediately obvious is how you change the host or service console route, since there’s no Set-TkeVMHostRoute. In truth there should be a Set-TkeVMHostRoute and probably will be one at some point. But for now this can be done using New-TkeVMHostRoute, which will just override any existing settings.


Changing your service console IP is similar, except you will also need to specify your GatewayDevice. If you have multiple service console IPs you can set each of them by specifying different gateway devices.

If this stuff looks useful to you, be sure to check out the VI Toolkit Extensions for this and a lot more great stuff. You should keep in mind that the extensions require PowerShell v2 CTP3, which is still in technical preview mode. But if that’s something you can use anyway you’ll find it to be extremely helpful.