Fixing a VM that had AutoAddVTPM set: Difference between revisions
mNo edit summary |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 3: | Line 3: | ||
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. | 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 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 === | === Here's one solution where you have a few manual steps === | ||
| Line 9: | Line 11: | ||
The steps to recover your VM are as follows: | 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: | The steps are basically: | ||
| Line 30: | Line 37: | ||
That ''should'' be all. | 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? | |||
Latest revision as of 18:05, 22 September 2023
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?
