Ever had one of those moments when someone shows you something that’s a whole lot simpler than what you had in mind? I just had one of those moments. For a long time I’ve wanted the ability to script VMX file changes because there’s a lot of really important and useful stuff you can do with VMX files that you can’t do any other way. With the recent changes to the VI Toolkit Community Extensions (more on that later) I had decided that I was finally close enough to do it, and was going to make it my weekend project (don’t laugh). Out of the blue comes a script from Benjamin Attal, a VMware consultant in France that does exactly what I wanted to do, except his approach is really easy!
It’s also a testament to the depth and power of the VMware API. Adding a key/value pair to every VMX file for every VM is as simple as this:
|
1 2 3 4 5 6 7 8 9 10 |
$key = "Key to set" $value = "Value to set" get-vm | foreach { $vm = Get-View $_.Id $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec $vmConfigSpec.extraconfig += New-Object VMware.Vim.optionvalue $vmConfigSpec.extraconfig[0].Key=$key $vmConfigSpec.extraconfig[0].Value=$value $vm.ReconfigVM($vmConfigSpec) } |
If every VM is too broad, all you have to do is pass a name (wildcards supported) to get-vm and you can target specific VMs or sets of VMs.
Great, so what do I do with that?
It’s not immediately clear why anyone would care about this. The reason is that there’s some really useful stuff you can do through the VMX file that it is not possible to do using VI Client. I want to focus the rest of this post around two use cases.
The VMX file is a dark, mysterious place, full of hidden surprises. To my knowledge there is no definitive source of information on what options are available and what they do. One piece of useful information can be found in a VMware KB article that discusses how to change VM logging behavior. By changing the "log.rotateSize" and "log.keepOld" keys you can keep more or less log information about your VMs, as your needs dictate. To do that you can either use the script above, changing the $key and $value variables as appropriate, or read the section below for how to do it with the community extensions.
A second really useful thing you can do with VMX files is described by Eric Siebert, who talks about how to change the location where VMware writes snapshots. As I’ve discussed before, snapshots can cause big problems when they are left unchecked. Some people place snapshots on a separate datastore so that if that datastore fills up it won’t interfere with provisioning new systems. Setting the "workingDir" VMX key lets you do that very easily.
Community Extensions
I’ve been meaning to write about how there’s been a whole lot of useful stuff added to the community extensions. I’ll try to update later in the week about some of the new stuff, but for now let’s stick with the VMX theme. We’ve added a cmdlet called set-tkevmx that provides a very simple interface for changing your VMX file. If you download the extension (available on CodePlex) and add it using add-module viToolkitExtensions.psm1, you can then do the stuff mentioned above as easily as this:
|
1 |
<p>get-vm | set-tkevmx -key log.rotatesize -value 10000</p> |
This will set the log rotate size on ALL your VMs to 10,000.
|
1 |
<p>get-vm | set-tkevmx -key workingDir -value /path/to/lots/of/storage</p> |
This will change every VM you’ve got to store its snapshots and vswp files to an alternative location.
Just for the sake of re-iteration, to run the code above you’ll need PowerShell CTP2 V2, the VI Toolkit for Windows and the VI Toolkit Community Extensions. Enjoy!
