The

removeKey

and

removeKeys

methods delete key(s) from vCenter Server, but they do not delete keys from the KMS. Key lifecycle is managed entirely from the KMS, where stale keys persist. You can invoke the

listKeys

method to show keys in use on the vCenter Server, but there is currently no method to query whether a specific key is in use.

The

force

parameter of

removeKey

and

removeKeys

should be used judiciously. With the

force

option, the

removeKey

and

removeKeys

methods delete key(s) from both the vCenter Server and ESXi hosts, even if the key is currently in use. The result can leave virtual machines in a locked state until the key is replaced. The use case for the force option is for customers to prevent a key from being used anywhere, after it was compromised or expired.

If you call

removeKey

on an ESXi host, even without the

force

option, the key gets deleted from the host’s key cache, and the encrypted virtual machine becomes unusable. ESXi hosts do not track which keys are in use. Rebooting the ESXi host causes vCenter Server to push all keys to the host again, but the virtual machine may not be fully recoverable from its failed state.

When you encrypt both a virtual machine and its virtual disks from the vSphere Client, the same key is used for both. When you encrypt a virtual machine and its disks using the API, you can set different encryption keys for the virtual machine and each virtual disk. If one of the disk keys is missing, the power on operation may fail. If the missing key is for a non-boot virtual disk, you can remove that disk from the virtual machine and retry the power on operation. Take care when managing the lifecycle of different keys for a virtual machine and its disks.

The

registerVM_Task

method can rename a virtual machine at registration time. In vSphere 6.5 this required a two-step workaround for encrypted virtual machines, but in vSphere 6.7, this operation is supported with encryption. Also in vSphere 6.7, the

reloadVirtualMachineFromPath_Task

is supported for encrypted virtual machines. The reload API is equivalent to unregistering and registering a virtual machine on a different configuration path.

For security on vSAN datastores, you should use vSAN encryption instead of virtual machine encryption. This is because vSAN encryption is designed to be compatible with deduplication and compression. Whereas virtual machine encryption causes vSAN deduplication and compression to become less effective.

There are many reasons why an encrypted virtual machine could be, in effect, locked. For solutions, see section “Resolve Missing Key Issues” in the

vSphere Security

manual.

In vSphere 6.7 and later you can unlock locked virtual machines with the

cryptoUnlock_Task

method. A vCenter Server alarm notifies you when an encrypted virtual machine is in a locked state. To unlock it you must have

Cryptographic operations.RegisterVM

privilege. Before unlocking, it is a good idea to troubleshoot and attempt to fix the cause of the locked virtual machine. The

cryptoUnlock_Task

method takes one parameter, the

MoRef

of a virtual machine.