vSphere Encryption- Knowing your limits

I’ve been running a Proof of Concept system for vSphere Encryption using vSphere 6.5u1 and a HyTrust KeyControl 4.0 KMS cluster. This has been very straightforward to implement and use and there’s plenty of documentation out there on how to do so, but in this post I’ll be highlighting some of the limitations. A few of these are things you can’t do that you may currently do day-to-day with normal VMs but there’s usually a sound technical reason why it’s not possible to do so with an encrypted VM.

Encrypting and Decrypting

The power state of a VM limits some encryption processes. For example, a powered-on Virtual machine can not be encrypted or decrypted. This example shows what happens when PowerCLI (with the encryption module described here) is used to encrypt a running VM:

1PS C:\> Get-VM -Name "KMSTest6" | Disable-VMEncryption
2Disable-VMEncryption : The VM can only be decrypted when powered off,
3but the current power state of KMSTest6 is PoweredOn!

The encryption can be changed (a re-key operation), possibly to a different KMS server- however whilst a “Shallow Re-key” operation where the key is re-encrypted is fine, the “Deep Re-key” where the disk itself is re-encrypted with the new key is not possible when the VM is powered on.

Snapshots and Clones

Similarly, a snapshot including memory of a running VM is not possible. It is possible to snapshot a powered off VM, or a running VM without the memory state (which creates a powered-off snapshot), but not to include the memory. This makes sense as the VM Encryption process runs as the hypervisor writes to disk, memory would be outside this process and potentially reveal unencrypted data in the snapshot.

It’s also not possible to decrypt or encrypt a VM with snapshots:

1PS C:\> Get-VM -Name "KMSTest5" | Enable-VMEncryption
2Enable-VMEncryption : KMSTest5 has snapshots,
3please remove all snapshots and try again!

You can however clone an encrypted VM- the resulting clone is also encrypted and uses the same keys. vMotion also works as expected.

Replication

vSphere Replication does not work with encrypted VMs. Replication can be configured but will fail when it tries to sync.

Licensing

In most environments where vSphere Encryption is in use, the hosts will probably be all licensed with Enterprise Plus (see the license comparison table). However, if you are running a mixture of licenses (including any regular non-plus Enterprise licenses) the limitations of  those licenses comes into play. It’s not possible to turn on encryption on a VM allocated to a host with anything but a full Enterprise-Plus license.

Any hosts with Standard, or the no longer available to purchase Enterprise licenses will not allow their VMs to be encrypted- or for encrypted VMs to be migrated onto them. Additionally if you have one or more of these “inferior” hosts in a cluster you will not be able to power on an encrypted machine in that cluster- even if other hosts are licensed to Enterprise Plus.

Disks

There’s lots of flexibility down at the disk level. You can use different keys (or even KMS Clusters) for different virtual hard disks (i.e. each .vmdk has a different key) and you can take an encrypted disk and attach it to another VM. The limitation here is you cannot attach an encrypted virtual hard disk to an unencrypted VM- this again makes sense as the key information in the configuration would then be in the clear.

Summary

The encryption model introduced in vSphere 6.5 is a very useful feature and straightforward to implement however consideration needs to be taken on the continuing activities surrounding virtual machines post-encryption to ensure that operational processes are still valid.