In vSphere 7.0 Update 2 and later, encrypted virtual machines and virtual TPMs can continue to optionally function even when the key server is temporarily offline or unavailable. The ESXi hosts can persist the encryption keys to continue encryption and vTPM operations.

Before vSphere 7.0 Update 2, encrypted virtual machines and vTPMs require that the key server always is available to function. In vSphere 7.0 Update 2 and later, encrypted devices can function even when access to a key server is disrupted.

In vSphere 7.0 Update 3 and later, encrypted vSAN clusters can also function even when access to a key provider is disrupted.

Note: Key persistence is not necessary when using vSphere Native Key Provider. vSphere Native Key Provider is designed out-of-the-box to run without requiring access to a key server. See the following section, "Key Persistence and vSphere Native Key Provider."

How Does Key Persistence on ESXi Hosts Work

When using a standard key provider, the ESXi host relies on vCenter Server to manage the encryption keys. When using a trusted key provider, the ESXi host relies directly on the Trust Authority Hosts for keys, and vCenter Server is not involved. vSphere Native Key Provider handles keys differently. See the next section for more information.

Regardless of the type of key provider, the ESXi host obtains the keys initially and retains them in its key cache. If the ESXi host reboots, it loses its key cache. The ESXi host then requests the keys again, either from the key server (standard key provider), or the Trust Authority Hosts (trusted key provider). When the ESXi host tries to obtain keys and the key server is offline or unreachable, vTPMs and workload encryption cannot function. For edge-style deployments, in which a key server is typically not deployed on site, a loss of connectivity to a key server can cause unnecessary downtime for encrypted workloads.

In vSphere 7.0 Update 2 and later, encrypted workloads can continue to function even when the key server is offline or unreachable. If the ESXi host has a TPM, the encryption keys are persisted in the TPM across reboots. So, even if an ESXi host reboots, the host does not need to request encryption keys. Also, encryption and decryption operations can continue when the key server is unavailable, because the keys have persisted in the TPM. In essence, depending on the key provider, when either the key server or Trust Authority Hosts are unavailable, you can keep running encrypted workloads "key server free." Also, vTPMs can likewise continue to function even when the key server is unreachable.

Key Persistence and vSphere Native Key Provider

When using a vSphere Native Key Provider, vSphere generates encryption keys and no key server is required. The ESXi hosts get a Key Derivation Key (KDK), which is used to derive other keys. After receiving the KDK and generating other keys, the ESXi hosts do not need access to vCenter Server to do encryption operations. In essence, a vSphere Native Key Provider always runs "key server free."

The KDK persists on an ESXi host by default even after reboot, and even when vCenter Server is not available after the host reboots.

You can activate key persistence with vSphere Native Key Provider, but it is normally unnecessary. The ESXi hosts have complete access to vSphere Native Key Provider and so additional persistence of keys is redundant. One use case for activating key persistence with vSphere Native Key Provider is when you also have a standard key provider (external KMIP server) configured.

How Do You Set Up Key Persistence

To activate or deactivate key persistence, see Activate and Deactivate Key Persistence on an ESXi Host.