Protecting stored data is only one element of security; you also need to encrypt the network connections. For the infrastructure part, all of the communication between vCenter and the hosts is usually encrypted. However, some other infrastructural network traffic usually is not protected; for example, iSCSI or NFS traffic (and also vMotion, until vSphere 6.5).
Starting with vSphere 6.5, vSphere vMotion always uses encryption when migrating encrypted virtual machines. For virtual machines that are not encrypted, you can select one of the encrypted vSphere vMotion options.
Encrypted vSphere vMotion secures confidentiality, integrity, and authenticity of data that is transferred with vSphere vMotion. Encrypted vSphere vMotion supports all variants of vSphere vMotion for unencrypted virtual machines, including migration across vCenter Server systems. Migration across vCenter Server systems is not supported for encrypted virtual machines.
For encrypted disks, the data is transmitted encrypted. For disks that are not encrypted, Storage vMotion encryption is not supported. For virtual machines that are encrypted, migration with vSphere vMotion always uses encrypted vSphere vMotion. You cannot turn off encrypted vSphere vMotion for encrypted virtual machines.
For virtual machines that are not encrypted, you can set encrypted vSphere vMotion to one of the following states. The default is Opportunistic.
| Option | Description |
|---|---|
| Disabled | Do not use encrypted vSphere vMotion. |
| Opportunistic | Use encrypted vSphere vMotion if source and destination hosts support it. Only ESXi versions 6.5 and later use encrypted vSphere vMotion. |
| Required | Allow only encrypted vSphere vMotion. If the source or destination host does not support encrypted vSphere vMotion, migration with vSphere vMotion is not allowed. |
When you encrypt a virtual machine, the virtual machine keeps a record of the current encrypted vSphere vMotion setting. If you later disable encryption for the virtual machine, the encrypted vMotion setting remains at Required until you change the setting explicitly. You can change the settings using Edit Settings.
Virtual Machine Encryption Best Practices
Follow virtual machine encryption best practices to avoid problems later, for example, when you generate a vm-support bundle.
General Best Practices
Follow these general best practices to avoid problems.
- Do not encrypt any vCenter Server Appliance virtual machines.
- If your ESXi host crashes, retrieve the support bundle as soon as possible. The host key must be available if you want to generate a support bundle that uses a password, or if you want to decrypt the core dump. If the host is rebooted, it is possible that the host key changes and you can no longer generate a support bundle with a password or decrypt core dumps in the support bundle with the host key.
- Manage KMS cluster names carefully. If the KMS cluster name changes for a KMS that is already in use, any VM that is encrypted with keys from that KMS enters an invalid state during power on or register. In that case, remove the KMS from the vCenter Server and add it with the cluster name that you used initially.
- Do not edit VMX files and VMDK descriptor files. These files contain the encryption bundle. It is possible that your changes make the virtual machine unrecoverable, and that the recovery problem cannot be fixed.
- The encryption process encrypts data on the host before it is written to storage. Backend storage features such as deduplication and compression might not be effective for encrypted virtual machines. Consider storage tradeoffs when using vSphere Virtual Machine Encryption.
- Encryption is CPU intensive. AES-NI significantly improves encryption performance. Enable AES-NI in your BIOS.
Conclusion
The vMotion encryption feature isn’t merely an encryption of the entire network channel for the vMotion traffic. There aren’t certificates to manage.
The encryption happens on a per-VM level; when the VM is migrated, a randomly generated, one-time-use 256-bit key is generated by vCenter (it does not use the KMS). In addition, a 64-bit nonce (an arbitrary number used only once in a crypto operation) is also generated. The encryption key and nonce are packaged into the migration specification sent to both hosts. At that point, all the VM vMotion data is encrypted with both the key and the nonce, ensuring that communications can’t be used to replay the data.