VMware vMotion allows a live migration of operational virtual machines between host systems. The technology has...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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
One size does not fit all when administrators develop a protection policy for specific applications. Learn about the configuration options in System ...continue reading
Set up and operate a VM network using proven strategies to ensure security and performance. With a little planning, virtualization admins can avoid ...continue reading
Virtual switch security is achieved through a number of features. Virtualization admins can create and enforce policies, lock down MAC addresses and ...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.