Many admins might think that encrypted vMotion is something that they don’t really need in their datacenter. However, when you’re using vMotion across hybrid or across public clouds, you leave your door open to threats. IT admins can protect critical VM data traveling across long distance and public clouds via a simple way in vSphere 7.
It is important to secure sensitive vMotion traffic at the network endpoints. This protects critical VM data when the vMotion traffic leaves the traditional IT environment and goes over the public networks.
Encrypted vMotion can make the process more secure with small effort from the admin in vSphere 7. No need for KMS if that’s your main concern. You’ll only need a vCenter server without any other software component installed.
The encryption keys that are used for the vMotion are ephemeral and not stored anywhere. They are present only temporarily in the memory of vCenter Server and the two ESXi hosts that are selected for the vMotion operation.
What is encrypted vMotion?
This feature has been introduced in vSphere 6.5 and uses end-to-end encryption for vMotion network traffic. You don’t need any additional hardware devices or hardware reconfiguration to configure and use encrypted vMotion in vSphere 7.
Encrypted vMotion encrypts all the data travelling across your VMkernel adapter and uses AES-GCM encryption. vSphere supports encrypted vMotion of unencrypted and encrypted virtual machines across vCenter Server instances.
When using encryption on a VM level and your VMDKs are encrypted, you can use storage vMotion. However, to set up a VM encryption, you’ll need to use a Key Management Server (KMS) as your VMDKs must be encrypted for storage vMotion.
Different encrypted vSphere 7 vMotion States
You should know that when setting up a vMotion, there can be 3 different encrypted vMotion states:
- 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, so if you have still some vSphere 6.0 hosts, they won’t be able to be used as a destination.
- Required – Allow only encrypted vSphere vMotion. In this case, if the source or destination host does not support encrypted vSphere vMotion, migration with vSphere vMotion is not allowed.
Note: If you’re using VM encryption on some of your VMs, those VMs are automatically vMotioned with encrypted vMotion.
Where to enable or disable encrypted vMotion in vSphere 7?
This is done at the VM level and your VM has to be turned OFF. Go and select your VM > Edit Settings > VM Options > Encryption. Here, select Encrypted vMotion from the drop-down menu.
Configure Encrypted vMotion Options on a VM
If you need to set vMotion encryption on many VMs, you can possibly use PowerCLI.
For vCenters configured with Linked mode
If a vMotion is between hosts managed by different vCenter Servers in Enhanced Linked Mode, those two vCenter servers need to use SSL connection.
In fact, the source vCenter Server that generates the migration specification passes it to the destination vCenter through an SSL channel. The vCenter Servers will protect their communications using TLS, and the key distribution communications between vCenter Server and the ESXi hosts is done over a connection protected by TLS.
Both the source and destination vCenter Server instances must be Version 7.0 or later. However, you can have a mix of ESXi 6.7 and 7.0 hosts within your environment. There are not any other requirements or components to install and (or) configure.
The schema from VMware looks like this.
Encrypted vMotion Across vCenter Servers Workflow
The performance impact is mitigated on newer ESXi hosts that use recent CPUs as there is a CPU overhead. However, encrypted vMotion does not slow down your VMs. Encrypted vMotion is only used when your VMs are being migrated between hosts and not during other circumstances. So, the small performance impact only occurs during the vMotion operation.
When your environment uses VMware vSAN for storage, and you’re using vSAN encryption, it’s perfectly fine to use encrypted vMotion. It’s a supported scenario.
Final words
When a VM using encrypted vMotion is moved from one host to another, there is a random 256-bit key created by the vCenter server. This information is sent to the hosts, however, the particular VM does not have access to the encryption information. The encryption is taking place inside the VMkernel, so there is no need for specialized hardware.
If you want to use storage vMotion and migrate VMs together with their VMDKs, you must set up KMS and use encrypted VMs where you have your VMDKs encrypted. If not, storage vMotion is not supported for disks that are not encrypted.
Many businesses rethink their security policy. There are more and more threats online and when using vMotion across public clouds within hybrid environment, it’s better to use it than not. Attackers that access the vMotion traffic won’t be able to exploit it to their advantage as if they would access the network traffic in the clear.
The implementation is very easy and while you cannot set the encrypted vMotion across the entire cluster, you can do that on a per-VM basis. You pick the VMs that will be eventually vMotioned within or to and from remote datacenters, and make sure that they’ll be using encrypted vMotion.
