In vSphere 6.5 VMware introduced the possibility to encrypt Virtual Machine data on a per VM basis. This is achieved by using VAIO filtering and a specific policy is used to indicate whether a VM needs to be encrypted or not.
With vSAN 6.6 another way of encryption was introduced which means that the entire vSAN datastore is encrypted and as a result every VM that is stored on the vSAN datastore gets encrypted (and hence no specific policy is required).
For both encryption methodologies a KMS server (or cluster of KMS servers for production environments) that supports the KMIP protocol needs to be installed and configured in vCenter. Although both vSphere and vSAN encryption can use the same configured KMS server/cluster there is a small but important difference in the way the keys that are required for encrypting the data are communicated to the ESXi hosts.
In the case of vSphere (VM) encryption, ESXi needs to be able to communicate to vCenter to get the specific Key Encryption Key (KEK) for a VM when this VM needs to start (or is created). So when vCenter is not available, such actions possibly cannot be initiated.
For vSAN encryption however, an ESXi host only needs to communicate with vCenter when vSAN encryption is enabled. At that moment the KEK ID’s required to store the Data Encryption Keys (DEK) that are used to encrypt the disks are sent from vCenter to the ESXi hosts. Using these KEK ID’s the host will communicate directly with the KMS server to get the actual KEK.
To show this mechanism I have created a little demo video. For my own educational purpose I have used the vSphere (and vSAN) 6.7 version which allows me to use the new vSphere (HTML5) client functionality.