Category VMware Workstation

Updates:
2021/12/15, added near the end,
2022/01/24, “” “” “” “”
2022/01/27, “” “” “” “”

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
version=1
encoding="UTF-8"
CID=290130a2
parentCID=ffffffff
createType="twoGbMaxExtentSparse"

# 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

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?

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.

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

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)

Edit 2021/12/15

Note that the inability to copy the VM to another hosts is only a limitation with the experimental vTPM feature. If your VM is fully encrypted you can copy it to a another host, see also this post by VMTN user DVE2000 “How easy is it to move a TPM2 Win11 VM to another host?“

Hopefully this will not be a limitation once this is no longer an experimental feature. VMware is aware about this.

Edit 2022/01/24

Note that the experimental vTPM feature does not work on VMware Workstation running on Linux hosts. For now this only works on Windows hosts (and on macOS when running VMware Fusion)

See also this forum thread: TPM and Secure Boot errors on Windows 11 preview vm

Edit 2022/01/27

The following is a trick posted by reddit user dmartin-ames in thread Lessons upgrading Windows 10 guest to Windows 11

If you encrypt a VM based that is based on a linked clone then your base image can be unencrypted. The VM then only has a small encrypted delta disk. This was tested with a fully encrypted VM, but is probably interesting to know for here as well.

Edit 2022/07/06

The following reddit thread describes how-to remove the vTPM when your virtual disk is a single filek disk which has the metadata embedded: Move a Windows 11 VM (with TPM) to a new computer

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 😉