VMware vMotion allows a live migration of operational virtual machines between host systems. The technology has...
been around for years and is well-proven. But the risk of compromise due to unencrypted data moving across the network (in flight) has promoted VMware to add encrypted vMotion in vSphere 6.5.
Encryption can ensure that any data involved in a migration arrives at a destination host intact and unaltered -- you can't read or change the encrypted content.
Although encrypted vMotion is easy to enable, it's important for administrators to understand the associated rules. Storage vMotion supports encryption, but only if the disk volume is already encrypted. If the disk volume isn't encrypted (at rest), Storage vMotion isn't available (in flight).
Encrypted vMotion also works for VMs. A VM that is already encrypted -- with VM encryption -- will always use vSphere encrypted vMotion. You can't turn off encryption in flight when the VM is already encrypted at rest. Encryption will continue for migration even if the VM encryption is later removed (disabled) or until the migration preference is manually changed.
However, if a VM is not already encrypted, administrators can choose to forego encryption (disabled), use encryption if the destination host is ESXi 6.5 compatible (opportunistic), or enforce encryption where migration isn't allowed if the destination host doesn't support it. This behavior can complicate environments where different versions of vSphere/ESXi may be in use. To make full use of vMotion encryption, all destination systems will need vSphere/ESXi 6.5 or later.
An interesting attribute of encrypted vMotion is that the encryption/decryption process takes place on a per-VM level. That means the VM is encrypted instead of the network. This eliminates any encryption-sensitive network configuration changes or certificate management issues that can complicate typical encryption techniques.
VCenter produces a random 256-bit key, along with a random 64-bit one-time code (a nonce). VCenter sends the key and code to both the source and destination host -- guest operating systems don't have access to the encryption keys.
The source uses the key and code to encrypt the VM, and the destination uses the same key and code to decrypt the VM. Users can't play back or hack the VM's migration data stream because of the use of a one-time code.
Beyond the need for vSphere 6.5 or later, there are several issues to consider when planning for vMotion encryption. First, you need an encryption key management system outside of vSphere. There can be an impact on the backup processes because there is only support for Ethernet backup traffic. This means cross-SAN backups are not available. In addition, options such as suspend/resume, VM encryption with snapshots, vSphere replication, and content library features are not currently supported.
VSphere 6.5 emphasizes security
Using virtualization security management to protect your infrastructure
How Horizon 7 Smart Policies gives security a boost
Dig Deeper on Securing a VMware environment
Related Q&A from Stephen J. Bigelow
Containers have rapidly come into focus as a popular option for deploying applications, but they have limitations and are fundamentally different ... Continue Reading
Senior technology editor Stephen Bigelow breaks down how AWS Storage Gateway can trip up users' hybrid cloud strategies. Beware these issues with ... Continue Reading
There is a small list of enterprise-class deployments and integrations known to run on VMware Cloud on AWS, but not all complex workloads are suited ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.