Fixing a VM that had AutoAddVTPM set

From VI-Toolkit
Jump to navigation Jump to search

You might have made the mistake to use an experimental solution that was offered for a while by VMware to install Windows 11 as guest OS. It involved adding a line to the .vmx file and after that you could add a TPM and thus install Windows 11. This would encrypt parts of the VM, but not give you a password and as such some people to find out that their VM won't work on some other hosts. The good part is that your data isn't actually encrypted, the bad part is that it isn't easy perse to get the data out.

The following article: https://www.vimalin.com/blog/what-you-should-know-about-vmwares-experimental-vtpm/ has the technical background on what happens if you have used this experimental feature and is good background knowledge if you try to start trying to recover your VM.

Here's one solution where you have a few manual steps

The steps to recover your VM are as follows:

This reddit thread here has the steps: https://www.reddit.com/r/vmware/comments/qy9wns/comment/hmokzl7/ where I helped a user getting back their VM.

For this type of VM none of the data is encrypted and only the descriptor files are encrypted. You can recreate the descriptor files and get back to a functional VM. If you haven't resized the virtual disks over time then it is a matter of creating a new VM with the exact same virtual disk in size.

That would be enough to get the descriptor data to copy over into the currently encrypted descriptor files. That should work.

If OTOH you have increased the size of your virtual disks over time then you have to repeat that increase in the exact same manner.

The steps are basically:

  • Create a new VM with a virtual disk of the same size as the encrypted one, make sure it has the same name.
  • use the new descriptor file ('MK Win Desktop.vmdk')
  • use the old vmdk data files ('MK Win Desktop-s001.vmdk' (001 to 016)
  • use the old .vmx file, but remove the lines that start with:
   managedVM.autoAddVTPM
   managedVM.ID
   encryption.encryptedKey
   encryption.keySafe
   encryption.data

If there's no snapshots then you don't need .vmsd (don't copy it in the new vm, delete if there)

Normally also no need for .nvram and .vmxf

That should be all.

One final note is that it is highly recommended to never touch your original VM and instead work with copies of the data while you try to get your VM back up and running. That way if you make a mistake you can just redo the steps. Otherwise you might introduce more problems and who needs yet another problem?