Starting with vSphere 6.7, users have been able to add a Virtual Trusted Platform Module (vTPM) to a VM, enabling guest operating systems to create and store private keys using a software-based representation of a physical TPM 2.0 chip, that is completely transparent to the underlying OS.
A major benefit of using vTPM is that a physical TPM chip is NOT required in the underlying ESXi host and the vTPM secrets are protected by encrypting the .nvram file, where the secrets are stored.
The encryption keys that are used to encrypt the vTPM is provisioned by a key provider, which can be either be an external Standard Key Provider (SKP) that is KMIP-compliant or using vCenter Server's built-in Native Key Provider (NKP). It is the management of these key providers and their workflows that requires the use of vCenter Server, providing a centralized control plane and a seamless user experience when using the vTPM feature.
Most recently, I saw an influx of inquiries from our field and customers asking about using vTPM with a standalone ESXi host that is NOT managed by vCenter Server, primarily for homelab purposes. While this question has come up in the past, the increased interests might be due to more folks looking to deploy Windows 11, which now has a requirement of a TPM.
While sharing this observation with our lead engineer for VM Encryption, I came to learn that while vCenter Server is highly recommended for a good vTPM user experience, it is technically NOT required for vTPM to function. This sounded very intriguing but surely this solution would NOT be supported right?!
Interestingly, vCenter Server simply uses a set of public vSphere APIs that are available directly on an ESXi host to add or remove encryption keys that is generated from the key provider but the functionality to manage the encryption keys are available on an ESXi host. While this "manual" method is not as seamless as using vCenter Server, you can enable vTPM for a VM using a standalone ESXi host that is not managed by vCenter Server in a completely supported manner!
The lesson here, do not always assume something is NOT supported until you have been told it is NOT supported and always be learning! 😁
🚨 ⚠️ Please carefully ready through the Key Persistency section FIRST before proceeding any further! You have been WARNED ⚠️ 🚨
To demonstrate the Crypto vSphere APIs on an ESXi host, I have created several PowerCLI functions that makes it very easy for anyone to setup vTPM for a standalone ESXi host not managed by vCenter Server. I will not bore you with the implementation details, but if you are really interested, you can look at the source code in the vTPMStandaloneESXiFunctions.ps1 file. For my setup, I am using an Intel NUC 13 Pro, which does NOT have a compliant TPM chip that ESXi recognizes just to prove that you can get this solution working on pretty much any hardware platform that is using ESXi 6.7 or later.
Note: You will need a licensed ESXi host, basically anything EXCEPT for Free ESXi Hypervisor license as that only provides you with read-only access to vSphere API
Step 1 - Download and source the functions vTPMStandaloneESXiFunctions.ps1 file by running the following command:
Step 2 - Use the Connect-VIServer to connect to your standalone ESXi host using:
Connect-VIServer -Server 192.168.30.62 -User root
Step 3 - Run the Prepare-VMHostForEncryption function which will prepare the ESXi host for encryption:
New-InitialVMHostKey -Operation CREATE -KeyName "host-key-1"
Step 5 - Next, we can now generate new VM encryption keys that will then be used to encrypt the vTPM device for a given VM by running the New-VMTPMKey function and provide a name for the key (use something descriptive such as the VM name that you intend to use the key):
New-VMTPMKey -Operation CREATE -KeyName "windows-11-key"
Step 6 - We can also list all host and VM encryption keys by using the Get-VMHostTPMKeys function, which is useful to see what keys are stored on the ESXi host, especially for consuming the VM encryption keys when adding a vTPM device to a VM:
Reconfigure-VMWithvTPM -KeyName "windows-11-key" -VMName "Windows-11"
If everything was succesful, you should now be able to power on a VM and consume the vTPM as demonstrated in screenshot below, which I was using a Windows 11 VM. Since the ESXi Embedded Host Client is not aware of the vTPM workflow, you will not see the device listed in the summary view, you will only see that if in the edit view of the VM as shown in the screenshot below.
If you need to remove a VM encryption key, you can use the Remove-VMTPMKey function and provide the name of the key. In the scenario where you need to forcefully remove a VM encryption key, you can use the -Force $true option as shown in the screenshot below.
Remove-VMTPMKey -KeyName "windows-11-key"
By default, ESXi does NOT store or save any encryption keys across reboots! You will need to re-add all host and any VM encryption keys that have been assigned to a VM or you will not be able to power on the VM. This is one of the major benefits and functions that vCenter Server provides by managing encryption keys that are provisioned by a SKP or NKP to the respective ESXi hosts to ensure they are available.
As a workaround, I have implemented an automatic encryption key backup each time a host or VM encryption key is generated using the PowerCLI functions. The encryption keys are automatically saved to a CSV file named tpm-keys.csv by default or you can choose your own name. Using the encryption key backup file, we can then easily re-import all encryption keys back on an ESXi host.
This is where having a physical TPM would be extremely useful! If you have a physical AND compliant TPM 2.0 chip (requires FIFO and NOT CRB protocol which is typically found in many consumer platforms and is not supported), then you can enable the Key Persistency feature in ESXi using the instructions outlined here, which will then automatically persist all encryption keys that have been added to an ESXi host whether that is manually through the use of the vSphere APIs through vCenter Server and store them on the TPM chip.
If you do NOT have a physical AND compliant TPM 2.0 chip then we simply need to ensure that we have a backup of the generated host and VM encryption keys, which are saved by default in the tpm-keys.csv file. We will go through a simliar enablement workflow of preparing the ESXi host, but rather then generating a new host encryption key, we will simply import our existing host and VM encryption keys that were created earlier.
Here is an example of using the same functions but now using the IMPORT operation which will look for the specific host or VM encryption key name from a given CSV file (default is tpm-keys.csv):
New-InitialVMHostKey -Operation IMPORT -KeyName "host-key-1" -CSVTPMKeyFile tpm-keys.csv
New-VMTPMKey -Operation IMPORT -KeyName "windows-11-key" -CSVTPMKeyFile tpm-keys.csv
While I have not confirmed myself, but I suspect this solution could also benefit standalone ESXi-Arm as today, you would need to setup an x86 vCenter Server using SKP or NKP.