StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

VMware vSphere 7 and Encrypted vMotion – All You Need to Know

  • December 15, 2020
  • 10 min read
IT and Virtualization Consultant. Vladan is the founder, and executive editor of the ESX Virtualization Blog at He is a VMware VCAP-DCA and VCAP-DCD, and has been a vExpert from 2009 to 2023.
IT and Virtualization Consultant. Vladan is the founder, and executive editor of the ESX Virtualization Blog at He is a VMware VCAP-DCA and VCAP-DCD, and has been a vExpert from 2009 to 2023.

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

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

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.

Found Vladan’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!