What you should know about VMware’s experimental vTPM

Note: This is a live document which will be updated with details as they come in. (Last update: 2021/10/23)

VMware recently released Workstation 16.2 and Fusion 12.2. One of the exciting new features is an experimental vTPM implementation that doesn’t need encryption to help with Windows 11 virtual machines. This however is not the complete story and in my opinion you need to know more details before using this experimental feature.
In the rest of this document I will use the word “Workstation”, but if you’re using Fusion, read that as “Fusion”, otherwise this article gets really hard to read.

The background

Microsoft Windows 11 now requires a TPM device. You have been able to use a TPM device in your virtual machines since Workstation 14 (Fusion 10). In the past however, you would have to encrypt your entire Virtual Machine using VMware’s encryption logic before you can add the TPM device. With the new experimental vTPM feature the virtual disk is no longer encrypted, thereby preventing additional performance loss. But that is only a part of the story.

The potential issue

While the virtual disk itself no longer gets encrypted, a lot of the other files -including disk descriptor files- are still encrypted. Worse even, the password used to encrypt these files is unknown to you. This can become a pretty big problem later on.

OK.. so far the overview, let’s step back and look at how this works and then describe this all in more details.

How to use the new experimental vTPM feature?

After upgrading to Workstation 16.2 (Fusion 12.2), shut down Workstation and add the following line to the vmx file of your virtual machine.

managedvm.autoAddVTPM = "software"

Then go back to VMware Workstation and open the virtual machine.
At that moment, a vTPM has been added to your VM and in addition the following new lines are also added to your .vmx file (with different details).

managedVM.ID = "52 e3 71 9f d0 ef 55 6e-7e f0 4e 05 51 d3 98 52"
encryption.encryptedKey = "AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAZKX7IXyss0.......CKw=="
encryption.keySafe = "vmware:key/list/(pair/(phrase/OrVWhvfQTLY%3d/pass2key%3dPBKDF2%2dHMAC%2dSHA%2d1%3acipher%3dAES%2d256%3arounds%3d10000%3asalt%3dUTYIUjqT6VPerQQfAvKY7Q%253d%253d,HMAC%2dSHA%2d1,yXJ3PmVy......3d))"
encryption.data = "4pKXS5ChzVg5gngF.......+OT2WswlLjgGzfajENWM5g=="

The rest of the .vmx file stays untouched.
So far, so good and if this was all that happened, then I would have been very happy with the vTPM implementation. This however is far from all that has happened to your VM.

The following files are now also encrypted:

the .vmsd file (which holds your snapshot meta data)
the .nvram file (your bios/efi data)
all your .vmsn/.vmss files (snapshot/suspend file state data)
all the vmem files (memory backing files)

and the worst one:
all the vmdk descriptor files. Your main vmdk descriptor files _and_ all the descriptor files of the vmdk snapshot files, including the snapshots taken before the vtpm was added.

Here’s an example of a .vmdk file before:

# Disk DescriptorFile

# Extent description
RW 8304640 SPARSE "Virtual Disk-s001.vmdk"
RW 8304640 SPARSE "Virtual Disk-s002.vmdk"
RW 8304640 SPARSE "Virtual Disk-s003.vmdk"
RW 8304640 SPARSE "Virtual Disk-s004.vmdk"
RW 8304640 SPARSE "Virtual Disk-s005.vmdk"
RW 8304640 SPARSE "Virtual Disk-s006.vmdk"
RW 8304640 SPARSE "Virtual Disk-s007.vmdk"
RW 8304640 SPARSE "Virtual Disk-s008.vmdk"
RW 2768896 SPARSE "Virtual Disk-s009.vmdk"

# The Disk Data Base 

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "4307"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "1136bc3f7e515f8ea97d7a12290130a2"
ddb.toolsInstallType = "1"
ddb.toolsVersion = "11301"
ddb.uuid = "60 00 C2 95 84 d5 b7 74-36 7e 25 b7 34 a0 f2 40"
ddb.virtualHWVersion = "11"

and how the vmdk descriptor file looks like afterwards:

[18]lsilogic[binary data]vmware:key/list/(pair/(null/%3cVMWARE%2dEMPTYSTRING%3e,HMAC%2dSHA%2d1,%2b%2biOIPLnCp1AY2vI5IaOML7SxbI1%2fI….[lots of binary data]

Why might this be a problem?

Normally with any new experimental flag for a virtual machine you can go back to normal by removing the flag again.
As the autoVTPM flag has effectively altered your VM, just removing the flag again is not enough to completely go back.
You might be able to boot, but all the parts that had been encrypted, are still encrypted…. and you have no password.
Well it’s there, in the .vmx, but encrypted.

So what can you remove without damaging your VM?

Remove the line:

managedvm.autoAddVTPM = “software”

managedVM.ID = “52 e3 71 9f d0 ef 55 6e-7e f0 4e 05 51 d3 98 52”

encryption.encryptedKey = “AQAAANCMnd8BFdERjHoAwE/

encryption.data = “4pKXS5ChzVg5gngF…….+OT2WswlLjgGzfajENWM5g==”

encryption.keySafe = “vmware:key/list/(pair/(phrase/OrVWhvfQTLY%3d/…


Removing that should not break your VM unless you used a feature depending on a TPM such as bitlocker. Windows 11 will ask you to setup the login PIN again.

Does not break your VM either

VM no longer boots (Enter Password => “This virtual machine is encrypted…”), can’t edit settings in Workstation either

Error: Could not open vmx, internal error

VM no longer boots (The disk ‘yadayada.vmdk’ is encrypted and a required key was not found. Cannot decrypt disk because key or password is incorrect

So this means that if you overwrite your .vmx file with a earlier copy of your VM that you can no longer open or edit that VM as the lines above are all missing.
In order to go back to the same state before you should restore the other files and optionally remove files that are automatically recreated when missing (such as .nvram, .vmsd, .vmxf)

Additional Side effects

Several automation API’s no longer work.

For example: Both starting your VM and take or commit snapshots, no longer work as expected. Those operations now require you to enter a password (which was never given).

You can still take a snapshot when a VM does not run.
However when the VM is running you get an error if you try:

C:\>"C:\Program Files (x86)\VMware\VMware Workstation"\vmrun -T ws snapshot "C:\VMs\Windows\Windows.vmx" "testsnapshot2"
Error: Authentication for encrypted virtual machine failed

or start a VM

C:\>"C:\Program Files (x86)\VMware\VMware Workstation"\vmrun -T ws start "C:\VMs\Windows\Windows.vmx"
Error: The operation is not supported

If you want to start your VM by trying to use vmware -x or vmware -X then that no longer works. It does start VMware Workstation and selects your VM, but it does not run the VM.

There’s a free disk space check when you add the new experimental vtpm feature. As a result you need to have free disk space for the full size of your virtual disk before you can apply the feature. Without sufficient free disk space, the vtpm is added partially and your VM might already be broken.

virtual machine in an inconsistent state

If you want to copy your VM to another host and run it there then you are out of luck. The VM only runs on your existing host and trying to open it on another host now results in the following screen:

Restore VM on a different host
Restoring a VM from another machine

You can’t decrypt the vmdk descriptor files as you don’t have the password. The remove encryption dialog demands a non empty password (not that the password is actually empty, I tried that)

Recommended steps to take before using the new experimental vTPM feature

  • Commit all your snapshots
  • Make sure that your virtual disk is using disk slices and not the – all in one file (monolithic)- virtual disk format. By using disk slices the descriptor files are separate files and easy to restore.
  • Make a copy of the following files in your VM: the .vmx file and all of your vmdk descriptor files. Optionally also make a copy of the .nvram and .vmsd files. Then if you want to go back to original state you can replace these files with the old copies. As long as you haven’t changed your VM configuration, not used bitlocker in the VM or other features that depend on that vTPM then you can roll back that way.
  • Make sure you have plenty of free disk space before trying this experimental feature.

Does this mean that you shouldn’t use this feature?

No, that’s not my message. I still think it is a great feature. It is however good to be aware about the changes it makes to your VM.
Experimental features are labeled like that for a reason. Sometimes the risk is just a crash, sometimes the risk is a bit bigger.
You should have made good backups of your important data already and -if not- then this hopefully reminds you to fix that 😉