PowerCLI: VM displayName -ne Name

If you were lucky enough to get a hold of @jasonboche vCalendar then this morning you were greeted with a tip regarding the DisplayName of a VM not matching it’s actual path.   As someone who has ran rm -rf  on more than one running vm because of this very issue.**  I will personally attest to why you should care about this!  Jason includes a link to Dominic’s solution in the calendar, but I’m not crazy about perl. So I wrote my own, PowerCLI find any VM with a naming issue.

So what does that do? Well for speed we start with Get-View, and only retrieve the Config property for each VM. Then we pass that collection through Where-Object. This is where PowerShell earns it’s name.

So -match will perform a regular expression comparison operation, So here if the VmPathName looks anything like vm/vm.vmx -match will return $true, and that object will be passed down the pipeline. That however is only part of the story. When PowerShell matches something with a regex it stores the results in $Matches. This means that we can easily look that data up later. In addition I’m naming my matches. if you look in my regex you’ll notice (?<folder>.+?). The ?<folder> will apply the parameter name “folder” to anything that is matched inside the parenthesis, How cool is that!

From there it becomes real easy to see what I’m doing. I compare the displayName with both the Folder name, and the name of the vmx. Then I pass anything that didn’t match to the Get-VIObjectByView Cmdlet.

So how did it do? Well I just scanned 600 VM’s in less than 20 sec, and found two problem children. There you have it, my PowerCLI vCalendar solution for September 10th, 2009! I’m really looking forward to the rest of this calendar, and all the possible automation goodness.


**Note your not screwed if you delete a running VM, take a deep breath, and DON’T power the VM off!  You’ll need to recreate several files, but you have time.  ESX/vSphere have a lock on everything the VM needs to run.

PowerCLI: Watch for VMHost Reboot

From time to time I try and update all bios/firmware/etc. While VMotion makes this all but a cinch, evacuating every host in succession puts quite a strain on DRS.   Therefore,  I try and patch everything when installing uudates.  I’ve developed my own little technique where I let VUM do it’s thing.  Catching the Host in the middle of the reboot, and update everything else.  While the actual update methodology changes from OEM to OEM.  I use the same simple little script for vSphere/ESX.  Basically, when I see the remediation task start for a host I kick this function off, “watching” that host, and walk away. Then when vCenter registers a VMHost reboot on the Host this little guy let’s me know.

In case you didn’t already know `a will cause your motherboard to beep.  That loud annoying  “I can hear it two cubicles over” beep!


PowerCLI: Update VMX Configuration Parameters (in mass)

My Virtual Infrastructure was recently audited.  As part of my preparation for said audit I needed to verify that several extra configuration Parameters were set on every VM. Nothing ground breaking, this has all been covered here, and here. So why the repost, well I’m obsessed with scaling! I don’t like doing anything that I can’t use to the nth degree. Having said that I found two simple tweaks that dramatically increased the performance of these scripts.

If you ever find yourself using where-object move back up the pipeline… can you use a filter instead? Here I dramatically improved performance by leveraging the built-in filter capabilities of Get-View. I was also able to crank it up by simply switching from the ReconfigVM method to the ReconfigVM_Task method. Unless your performing some serial action, always, always use the task method. Offloading the babysitting to vCenter just makes sense! Finally, I loath text files, especially when they create a needless dependencies. Here I use a simple hashtable to embed my configuration in the script it self.

I successfully used this script to update over 500 vm’s in less than 4min!  Now that is what I call scale!  I know the security experts our there would argue that this is meaningless, b/c of this or that… all I know is I passes my audit with flying colors (didn’t have one ding on a VM’s configuration).


PowerCLI: Evacuate a Datastore

More migration/upgrade stuff… As part of a larger migration strategy, I needed to migrate whole datastores. Literally Terabytes of VM data, while sVMotion did all the heavy lifting. I still needed a control script to manage this process for me. This script ran successfully for over three days on one of my larger datastores. Faithfully, moving my VM’s two by two!

Honestly I completed this over a month ago, but I consider these little scripts I write to be too simple to post… My drafts folder is full of stuff like this. On the one hand I want to post for my own use, but I can search my drafts for that. So I ask you, do you get any value out of these one off solutions? Please, don’t pad my ego… If you don’t find this kind of stuff useful don’t pretend. I have my documentation, I want to know if you would like access to it?

See ya’ll at VMworld

PowerCLI: Copy a ResourcePool(or a hundred)

As part of a larger migration I was recently given the task to copy all resource pools into new EVC enabled clusters. An already monotonous task was made worse by our use of resource pools for delegation. While it took a couple days to work out a recursion bug. The end product worked flawlessly, and successfully reproduced almost 100 resource pools across three clusters in less than 5min.

I mention the time lost because I truly believe you should “try” to script everything! In this case I lost some time, but I gained accuracy, and the ability to scale to the nth degree!

Read more

PowerCLI: Get every VM added to vCenter in the last 30 Days!

At seemingly random intervals I get requests from management to report every Virtual Machine that was added/removed in the last x days. This has traditionally been a manual process, and one that I loath.

While deploying a VM this morning I set up my normal tell me when your done one-liner…

As I was typing I wondered how long a task’s history was kept, and if I could query it via the SDK? Low and behold not only can I but it’s too easy!


PowerCLI Update VMware Tools without a reboot.

UPDATE:  This Functionality has been completely replaced with the Update-Tools cmdlet!

 UPDATE: 2009-7-31Recently several individuals have contacted me to report complications using my update-tools script. These issues center around my use, and dependency on WMI, and what appears to be vSphere 4 growing pains. Hopefully, the PowerCLI team can get this functionality built into the VUM cmdlets! Until then some assembly required!

There appears to be a bug in the VMwareToolsUpgrader.exe that will cause the system to reboot no matter what. This behavior is especially bothersome because the VI API simply calls that executable to perform any non-interactive upgrade.

This morning I was updating a smaller farm to 3.5u4. 15 minuets into the tools upgrade process I had enough… Enter PowerShell, I whipped up a quick script that will update All Windows VM’s to the latest version of VMware Tools.

Using this script I updated 50 Vm’s in 40min. There is alot of room for improvement here. I opted for the slow and steady pace, but larger environments could easily tune this to 100 at a time.


P.S. I started with Invoke-VMScript but only half of the vm’s had PowerShell installed, and I needed something that would hit them all.

PowerCLI SpeedBoost: Advanced functionality hidden within Get-View

Everyone knows how to use the Get-View cmdlet to retrieve the full managed object from a VI implementation (Impl) object, but did you know you can skip the Impl entirely? For instance have you ever needed the following?

If so you may want to try:

I’ve found the latter to be around 1200% faster!  Additionally, by selecting the properties of interest at run time  an additional performance boost can be obtained.  For example suppose you just wanted the Name of every ESX host in vCenter.

is 300% faster then the traditional

When you really need to optimize you VI Scripts just add some filters. For instance a 400% performance boost can be obtained by replacing,


but what if you need the Impl object?  It’s still 150% faster to convert back from the managed object that to retrieve then to get the impl in the first place.

Finally the grand pooh-bah of hidden potential… nested parameters within filters!  Say you want to locate all windows vm’s that have out of date tools.

traditionally we would approach this with something like,

Wait for it….

Over 800% faster and WAY less code! Although using get-view to it’s full potential can seriously increase your scripts performance I would leave it in your scripts.   The cmdlets provided in the PowerCLI are built around an interactive experience, the SDK is NOT!  While it may be faster to get all vm’s with get-view. The information returned from Get-VM is more useful when working from the cmdline.

Happy Scripting,

Bonus:  The function I was writing when I discovered this enhanced functionality… that’s right it was hidden in the help.

PowerShell: Removing VMware CPU/Memory resource limits

I recently assisted with a major hardware life cycle. We Migrated from Dell 1950’s to IBM BladeCenter H with H21XM blades. While the processors were comparable the RAM upgrade was tremendous. Going from 8/16GB to 32GB. This increase enabled much greater consolidation ratios, and with such we found ourselves with an abundance of hardware. After shutting down several hosts, and collapsing a few clusters we still weren’t driving our infrastructure. Shortly thereafter we realized that the resource limitations we had previously set. Were no longer necessary, and in some cases where decreasing performance (memory ballooning). A few minutes with the VI Toolkit for Windows, and we were screaming again!

Now all that is left is for Andrew to translate this to perl/rCLI.

Powershell: Working with the VI API (Teach a man to Fish)

I have a bunch of one off scripts and modules I’ve written for a VI Migration I performed last week. The task was to migrate a moderate VI farm (15 hosts 100+ vm) from AMD based server to Intel in a ridiculous 20min window. I played with the idea of setting masks in the vmx, but ultimately that itself would require a reboot. In the end I wrote a series of small scripts that handled the whole thing for me. That has become my MO as of late… get a task write a couple quick functions then a small script that uses those functions. I have to get approval from my client to post the scripts (even though there’s nothing in them they were written on their network) so in the mean time I thought I would share how I navigate the VI API, and create new functionality.

Read more