Return wandering VMs to their preferred ESX host

Return wandering VMs to their preferred ESX host

There are some cases where its desirable to have a VM running on a specific host in an ESX cluster. This may be operational (grouping VMs with similar service levels together), performance ("manual" load balancing, keeping "developer" VMs seperate from "production" VMs, etc.) or a number of other organizational specific reasons. Over time VMs may "drift" to other hosts due to vMotion moves for patching without the corresponding "move back", failure recovery performed by HA, or administrative reconfiguration. It would be useful to have a way to periodically move any misplaced VMs back to their preferred host. Out-of-the-box there is no capability in ESX or vCenter to provide this "return home" functionality.

Fortunately vCenter Server and the VI Toolkit for Windows provide the necessary infrastructure to implement a short script to perform the necessary moves.

  • vCenter Server allows additional custom fields to be added to a VM. These custom attributes are available via scripting as well as exposed in the VI Client UI under the "Annotations" field

  • VI Toolkit for Windows provides the necessary cmdlets to get/set the custom attributes as well as invoke vMotion to move VMs back to their preferred server

There are two scripts in the solution

  • UpdateTargetHost.ps1 - This script will walk through a set of VMs (either all VMs in a Data Center or the VMs in a specific folder) and set the "VM Target Host" custom attribute to the host where the VM is currently running.

  • MoveVMtoTargetHost.ps1 - This script will walk through a set of VMs (either all VMs or only those in a specific folder) and, if needed, move the VM back to the host specified in the "VM Target Host" custom field.

The UpdateTargetHost.ps1 script isn't strictly necessary; you could use the VI Client to create the "VM Target Host" custom field and then populate the field in each of your VMs. While that is ok for a few VMs it can be pretty time consuming and error prone as the number of VMs grows. The script provides a quick way of setting the VM's custom field to whatever host the VM is located on when the script is run. So typically you would move your VMs around until they are on the desired hosts, then run the UpdateTargetHost.ps1 script to record the host for each VM. In the future if the desired host placement changed, you could either manually update the custom field entry, or simply move the VMs to the desired hosts and re-run the script.

The MoveVMToTargetHost.ps1 script is meant to be run regularly to move any VMs that are not on their "target" host back to that host. It only operates on VMs that are powered on, and utilizes vMotion to perform the moves (so shared storage is required).

In each of the scripts there is a small customization section that allows you to update some site specific parameters. You'll need to edit these before using the scripts

  • Update the "connect-viserver InsertYourServerNameHere" to match the name of your vCenter server. So for example if your vCenter server is called "vc01.company.com" then the command would be "connect-viserver vc01.company.com"

  • The $LOC = Get-Folder "vm" line controls the scope of the changes. Leaving it set to "vm" will run the script against all VMs in vCenter, or you can change "vm" to be any folder name that exists in vCenter, in which case only VMs in that folder will be impacted. The script will not "walk" through mulitple levels of folders however, so if you have a nested folder hierarchy you'll need to create a copy of the script for each folder, or do some script modification to have it walk through nested folders

  • The $Verbose line controls whether status messages are sent to the console as the script runs. Its handy to leave at $True as you're testing the script and verifying that its working as you intended

You can run the scripts from within PowerShell, or from the command line. If you're running the script from the command line you'll need to include the VI Toolkit for Windows components as well when you invoke PowerShell. The command line below will run the MoveVMToTargetHost script stored in the C:\VCScripts directory

C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe -PSConsoleFile "C:\Program Files\VMware\Infrastructure\VIToolkitForWindows\vim.psc1" -Command C:\VCScripts\MoveVMToTargetHost.ps1

The functionality of the scripts is basic, there isn't a lot of error checking or "fancy stuff" being done. Buyer beward, YMMV, and above all test before using them!

A final word of caution is to think carefully of the consequences of using the script in conjunction with DRS, particularly if you schedule the script to run periodically. If DRS is in "Fully Automated" mode there is a chance (likely a very good one!) that it will "fight" with the scripts to move VMs around (i.e. DRS will move the VMs to balance load, which will cause some of the VMs to be on hosts other than their "target host", at which point the script will move them back, only to have DRS move them again, etc., etc., etc.). This VM movement "thrashing" will cause significant performance issues. But then again, if you're running DRS in "Fully Automated" mode you don't care what hosts your VMs run on, so you won't be using this script anyway Smiley Wink

Hopefully you'll find them useful, or at least a useful starting point for your own better-quicker-faster versions.

Attachments
Version history
Revision #:
1 of 1
Last update:
‎12-20-2008 10:55 PM
Updated by: