How to remove 'managedvm.autoAddVTPM = "software"' after enabling it in a vmx file?

[sanxell]

In VMware Workstation Pro 16.2, after setting managedvm.autoAddVTPM = "software" in a vmx file for a Windows 11 virtual machine, we can access it without an access control password.

But When I move the virtual machine to another computer and try to open it, the VMware Workstation Pro 16.2 asks me to enter a password to unlock it. Just like the old TPM solution. Obviously, there is no key here I can find. Because I didn't set it manually at all.

So, I decided to remove the setting after enabling it.

When I try to remove the experimental TPM device (managedvm.autoAddVTPM = "software"), the Vmware Workstation 16.2 access control still asks me to enter a password to remove the encryption.

Can anyone help me to deal with it?

[wila]

Hi,

I already answered this for you on reddit, but will copy it here for others.

If you used autoAddVTPM then the vm itself is not encrypted. If you want to remove the vTPM again then you will have to manually remove the new lines that were automatically added for the vtpm.

There's additional files to delete as well, the .vmxf, the .nvram and optionally the .vmsd. Note that the last one contains snapshot meta data, so if you have snapshots open, then you might want to make a backup of that one first.

Moderator note: Please don't post the same question more than one time, it makes it difficult for others to follow the discussion (and thus how it was fixed) I have removed your duplicate post.

--
Wil

[wila]

(Replying here as well as on reddit)

Hi,

I've been doing some more testing.

My apologies, it worked for me the other day, but that was with a squeeky clean VM. No guest OS installed.

I just redid the steps with a VM with a guest OS in there and as it turns out the vmdk descriptor files are fully encrypted as well.

Not seeing a difference in the actual data, but you will have to regenerate the actual vmdk descriptor files. Note that that is only easy if you do not use the "all in one file" vmdk file setup.

If you have an old copy of the descriptor file then you could put that back, if not then you can try and create a new VM with the exact same size disk and use the descriptor file from that.

edit: recreating a descriptor file only works if you haven't resized the disk over time. If you did resize the disk then you will have to follow those same steps (create VM with original vmdk size then resize it to the final size)

edit 2: I wrote a blog post about how this all works, with more details: https://www.vimalin.com/blog/what-you-should-know-about-vmwares-experimental-vtpm/

Hope this helps,
--
Wil

[OwenBurnett]

This feature is to be honest worse than having to encrypt the entire VM, because in the later case you at least can decrypt it again.

Here as it seams id you enable this the VM can't be decrypted anymore and you can't move the VM to an other PC!

please fix this properly, a common use case is to move VM's from one PC to an other and than everyhig must wok, espetially the snapshots!

[wila]

Hi,

Let me add another reddit thread, as it has some more details om how-to remove the experimental feature.

https://www.reddit.com/r/vmware/comments/qy9wns/virtual_tpm_chip_and_migrating_to_new_machine/

--
Wil

[HabibAzimi]

Hi,

I've done all your tips but it still wants a password from me. It seems that the snapshots are already cryptic... can I remove the snapshots to repair my VM? the main VMDK is possible not crypted...

[alexchandel]

Where does VMWare store the "password" when one adds "autoAddVTPM"?  Why doesn't it prompt for a password on the original machine?  Why isn't this better implemented?

[RDPetruska]

Realize that this is an undocumented, unsupported feature which VMware added as an experimental feature to assist users in creating Win11 guests.  I'm sure they are working on an improved version (as indicated by the product manager announcing a new tech preview of Fusion this week).   Stay tuned for more hopefully good news!