Hacked by adamblaze 2017 – http://twitter.com/adamblazex
– Irish Hacker –
The following script is a request from David Gontie, who was kind enough to comment on a previous post.
He’d like to add the location of his vm’s to a custom field. This is especially handy if you store all the files for a vm in a single datastore.
Here you go David:
Snapshots are m*th3rfcukers. If you’re not careful, they will mass-murder your vms. Yet they allow you to time-travel! You want to use them, but how to prevent a massacre? Here’s how: relocate the delta files.
When you create a snapshot, the current state of the vm is preserved by leaving the disk files alone. All changes since the moment of creating the snapshot are written to delta files. The delta files are stored in the vm’s working directory. The working directory is – by default – the location where the vmx and other config files reside. If that datastore runs out of free space – especially if it also contains disk files – you’re in a bit of a kerfuffle. Vms not booting or being frozen as if they stared into Medusa’s reptoid eyes.
So you can do two things: reserve overhead in your datastores and stay afraid some overactive snapshot might destroy your environment, or set the working directory of your vms to some big-ass datastore you don’t use for anything else and let the snapshots enjoy themselves. If they fill up the datastore, they only kill all vms with snapshots, not the rest.
But how, you ask? You can edit the vmx files of you vms manually – which requires your vms to be powered down – and add the line: workingDir = “/vmfs/volumes/<insanely long guid you need to somehow find>/”
Or, you run my script and change the working location on the fly:
WARNING: VMware vmotion does not check wether there are sufficient ports available on the virtual switch on the destination host. Migrating a vm to a host with insufficient ports will cause the vmotion to complete without warnings, yet the virtual NIC will be disconnected! This issue is descripbed in this KB article.
The solution to this problem is to create vSwitches with sufficient ports, obviously. Do you want to know how many ports are currently being used on every vSwitch in your environment? vSphere PowerCLI to the rescue! Try the following script: