A Trusted Platform Module (TPM) is a secure processor that handles cryptographic key generation, device authentication, and hardware tamper detection. A vTPM (Virtual Trusted Platform Module) is an emulated version of this device that you can attach to a VM. The guest OS sees and uses it the same way it would use a physical TPM on a physical machine.
How vTPM Works in SC//HyperCore
You create a vTPM when you first create and configure a VM, by selecting a vTPM-enabled Boot Type (see below). The vTPM is attached to the VM as a small block device, which the guest OS uses for operations that need a TPM.
- Both vTPM Boot Type options need SC//HyperCore™ HyperVisor 9.3 or later to appear as options you can select.
- vTPM state storage is not visible outside of the SC//HyperCore system’s own interaction with it.
- The vTPM block device stays attached to the VM through normal VM lifecycle operations: clone, replicate, export, and import.
- BIOS boot and vTPM are mutually exclusive — vTPM functionality requires a UEFI boot type.
- Once the vTPM is created, the SC//HyperCore web interface has no indicator that a VM has one attached, other than the Boot Type field. Check that the vTPM exists and is in use from inside the guest.
- A VM with a vTPM attached behaves the same as any other VM. The only extra considerations come from the in-guest security product that uses the vTPM.
Boot Type Options: UEFI + vTPM vs. UEFI + vTPM (Compatibility)
Both options create a VM with a vTPM, but they differ in the CPU generation they present to the guest OS:
| Boot Type | Emulated vCPU Generation | Purpose |
|---|---|---|
| UEFI + vTPM | Intel SkyLake | Full feature set of a SkyLake-generation CPU. |
| UEFI + vTPM (Compatibility) | Intel Haswell | Presents an older, more broadly compatible CPU generation so the VM can boot on older Scale Computing hardware — including for disaster recovery. |
This is critical for disaster recovery planning. This applies when a VM is protected with a vTPM and in-guest security features, and it replicates to a cluster that has any node with a CPU older than SkyLake generation. In that case, you must use the UEFI + vTPM (Compatibility) Boot Type. If you use the standard UEFI + vTPM type instead, the DR cluster may present a different underlying virtual CPU. The vTPM then reads this as hardware tampering, so on failover it denies access to the guest OS and any secured file systems or drives.
Even with the Compatibility boot type, portability has limits. TPM-backed features such as measured Secure Boot use a hardware, boot, and kernel “fingerprint” for attestation. So any change to the underlying virtual hardware can still cause the vTPM to deny access, if the change falls outside what the Compatibility CPU profile covers.
You can set Boot Type only when you create a VM, and you can’t change it afterward. See Create a Virtual Machine.
Primary Use Cases
Newer guest operating systems and in-guest security tools that depend on a TPM need a vTPM. The main examples are:
- Windows 11, which needs a TPM to install and run. See Supported Guest Operating Systems, or see In-Place Windows Upgrades to upgrade an existing Windows 10 VM to Windows 11.
- In-guest security solutions such as BitLocker.
Replicating and Recovering vTPM-Equipped VMs
You can replicate VMs that have a vTPM to other SC//HyperCore clusters. Before you do:
- Choose the right Boot Type by comparing the CPU generation of the Target cluster’s nodes to the Source (see the Boot Type table above).
- If you replicate a VM with a vTPM to a cluster that does not support vTPM functionality at all, the replication job fails with an error when you create it.
- If you use vTPM-related security features, retain any recovery keys generated by the in-guest security tool. Recovering a VM with a vTPM on a different hardware platform can trigger a vTPM lock, because the underlying hardware has changed. The recovery key may then be the only way back in.
- If hardware portability matters more to you than the security features themselves, consider removing TPM-dependent protections in the guest before backup or migration.
Removing a vTPM
A vTPM cannot be removed from a VM through the SC//HyperCore web interface once created. You can technically delete the NVRAM disk that holds the vTPM through the REST API, but this is strongly discouraged. If the guest OS is actively using the vTPM, removing it can make the VM permanently inaccessible.
If a vTPM-related security feature is causing issues, disable or remove that feature from inside the guest OS. Don’t try to remove the vTPM itself.