So, I've run into this issue a few times now, and since a google search of the error message returns basically nothing worthwhile (except for a VMware KB Article with basic CBT info) I thought I would write up the solution that I used in order to get this VM back up and running. Let me say thought before I get going, that if you have run into the same or similar situation, there is no guarantee that this method will work. it worked great in my environment, but there are many different issues that could cause this error, and this is only the fix for the one VM in my environment. Also be sure to open up a support ticket with VMware support as the last thing you want to do is cause further corruption to an already corrupted production virtual machine.

So first off the error message. "Invalid Signature in Change Tracking File". Basically, it seemed that on a snapshot creation, or consolidation, I'm not sure, one of my VMs would completely power off, and in attempts to power it back on I received this error. Immediately I responded by attempting to disable CBT, both on the VM and by commenting out the CBT lines in the vmx, however this did not resolve my situation. The error still occurred and the VM would not power on.

So essentially this points to some sort of corruption or issue within the change tracking file itself. The change tracking file (VM-NAME-ctk.vmdk) did exists in the VMs directory, so I moved on the Virtual disk descriptor file (VM-NAME.vmdk). If you edit this file you can see a line that defines the change tracking file as shown below. This is the line needs to be removed or commented out in order to continue. I personally like to make a backup of any file before I edit it, and would recommend doing that.

So look for a line that reads 'changeTrackPath="VMNAME-ctk.vmdk"' and comment that out. This is done by simply placing a # sign in front of the line. Once you are done that hit ESC and :wq to save and quit. Now we need to clone the disk (or disks if you have multiple) to another folder. This way we can play with the new disks and not effect the old (and if you are like me) untrusted disks that were generating the error. The command to use to clone the disk from ESXi console is..

vmkfstools -i /path/to/vm/VMNAME.vmdk /path/to/newvm/VMNAME.vmdk

Depending on the size and number of your virtual disks this can take a while.

Now it is time to go and remove the old vmdks from our VM and attach our newly created cloned disks. This is done through the vSphere client and is pretty straight forward but I've included some screenshots as a reminder.

First, right click the VM -> Edit Settings and we want to remove the original hard drives from the virtual machine. Select the Hard Disk that you wish to remove and click the 'Remove' button in the top left. Be sure to chose 'Remove from Virtual Machine' from the next screen. You might want to leave the original disks there and not Delete from disk, especially if VMware support is involved



Once you have removed all of your disks, click OK in order to apply all of your changes. Once it's gone through, Right Click the VM -> Edit Settings. Now we need to add our newly created and cloned vmdk's back to this VM. Click 'Add' and select Hard Disk as the Device Type to add. Be sure you add your disks back to the vm in the same order that they were in when you removed them.




When at the 'Select a disk' section, make sure you select 'Use an existing virtual disk' and not create a new one. Browse to the location of your cloned disks and select them, when done click 'OK' to apply everything. You should now be able to power on your vm (at least i was). Once you do so, a new change block tracking file will be created. Also, you probably should storage vMotion this VM somewhere else as well just to clean up all of the folder names as well. Hope this helps someone out, but again, be sure to contact VMware support if you have it!