Fixing a VM that had AutoAddVTPM set - Revision history

Wila at 17:05, 22 September 2023

2023-09-22T17:05:55Z

← Older revision		Revision as of 19:05, 22 September 2023
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 35:		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?

Wila: /* Here's one solution where you have a few manual steps */

2023-09-22T17:02:12Z

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

← Older revision		Revision as of 19:02, 22 September 2023
Line 9:		Line 9:
	The steps to recover your VM are as follows:		The steps to recover your VM are as follows:

	~~I've written out~~ the steps ~~here~~: https://www.reddit.com/r/vmware/comments/qy9wns/comment/hmokzl7/		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.

	~~Let me quote myself from one~~ of ~~my replies~~...		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:

Wila at 16:55, 22 September 2023

2023-09-22T16:55:34Z

← Older revision		Revision as of 18:55, 22 September 2023
Line 4:		Line 4:
	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.

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


Line 29:		Line 29:
	Normally also no need for .nvram and .vmxf		Normally also no need for .nvram and .vmxf

	That ~~__should__~~ be all.		That ''should'' be all.

Wila: Created page with "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 is..."

2023-09-22T16:53:59Z

Created page with "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 is..."

New page

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.

=== Here's one solution where you have a few manual setps ===

The steps to recover your VM are as follows:

I've written out the steps here: https://www.reddit.com/r/vmware/comments/qy9wns/comment/hmokzl7/

Let me quote myself from one of my replies...

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.