Many of the servers I’m operating exist in a VMware environment and were created on their Workstation platform before migrating to ESX. I had configured rolling, automatic snapshots under the Workstation environment where it was easily configurable and allowed me to, obviously, rollback any stupid changes I had made to my production images. However, after porting my images to ESX, the vSphere client did not allow me to edit this settings in any obvious fashion.

Laziness ensued and I went on my merry way only to discover these servers were consuming hundreds of gigabytes of provisioned space after several months had passed due to the fashion in which these snapshots were taken. I typically had to manually delete all the snapshots or consolidate them in order to recover diskspace. I passed this problem along to a VMware employee buddy of mine who advised:

“Boot up the VM. Point VMware Converter to the VM as if it was a physical server and convert it to a new VM. You’ll get a new VM without snapshots and without the automatic snapshotting.”

Needless to say, the downtime and unexpected effects of this action were not accepted and the change was never made. But still, a solution was needed. It turns out the problem was fixable much easier than that.

• Select the Virtual Machines tab enumerating your servers.
• Ensure the server in question is powered down.
• Right click on the server in question and select Edit Settings.
• Select the Options tab in the Virtual Machine Properties dialogue box.
• Highlight the General option under Advanced.
• Click on the Configuration Parameters button.

This will bring up a Configuration Parameters window similar to the following image. These same options can be edited directly on the .vmx file if you have that sort of direct access. Be advised, that if you are editing the .vmx file you follow VMware’s procedures for such editing.

Look through the configurations for entries keyed with rollingTierNN.XXXXX and snapshot.XXXXX. These are the entries that control snapshot timers, diskspace usage and ultimately timer behavior.

rollingTier0.clientFlags = "8"
rollingTier0.displayName = "AutoProtect Snapshot"
rollingTier0.interval = "86400"
rollingTier0.live = "TRUE"
rollingTier0.maximum = "4"
rollingTier0.timeSincelast = "1000"
rollingTier0.uid = "1"

rollingTier1.clientFlags = "8"
rollingTier1.displayName = "AutoProtect Snapshot"
rollingTier1.interval = "604800"
rollingTier1.live = "TRUE"
rollingTier1.maximum = "3"
rollingTier1.timeSincelast = "10000"
rollingTier1.uid = "2"

rollingTier2.clientFlags = "8"
rollingTier2.displayName = "AutoProtect Snapshot"
rollingTier2.interval = "2419200"
rollingTier2.live = "TRUE"
rollingTier2.maximum = "3"
rollingTier2.timeSincelast = "100000"
rollingTier2.uid = "3"

snapshot.numRollingTiers = "3"
snapshot.minFreeSpace = "1000000000000"
snapshot.maxSnapshots = "20"

First and foremost, you can get control of the snapshots back if you so desire by altering settings for snapshot.numRollingTiers, snapshot.maxSnapshots and snapshot.minFreeSpace. More than likely, only snapshot.numRollingTiers has been set if you initially configured it via VMware Workstation. Setting that value to 0 will disable the timers altogether. If you desire to retain the functionality, but gain more control over it, the other two keys let you limit the number of snapshots and also restrict snapshots from occurring if a requisite amount of minimum diskspace is not available.

Secondly, if maintaining the snapshots is important to you but you find their frequency obtrusive, you can edit the appropriate rollingTierNN key. Intuitively, increasing the rollingTierNN.interval value will result in less frequent snapshots being taken. I encountered mixed information on the meaning of the rollingTierNN.live key with one source indicated that a FALSE value will disable the timer’s action while another source indicated that a FALSE value will prevent including resident RAM from the snapshot.

Power up the server after making your changes and voilà … automatic snapshots under ESX are back under your control.