Study guide
2.3 vMotion & Enhanced vMotion Compatibility
VMware Certified Professional - Data Center Virtualization VCP-DCV
Track your progress as you read
Finished sections get a check mark.
1 Introduction: VCP-DCV Exam Overview
About the VCP-DCV Exam (2V0-21.23)
2 Chapter 1: vSphere Architecture & Core Platform Technologies
1.1 vSphere 8.x Architecture and Components Overview 1.2 vCenter Server Appliance (vCSA) Architecture & Deployment 1.3 vSphere Distributed Services Engine (DSE) & DPUs 1.4 vSphere Products, Solutions & Workload Platform 1.5 vCenter Topology: SSO Domains & Enhanced Linked Mode 1.6 vSphere with Tanzu: Supervisor, Namespaces, Zones & Lifecycle 1.7 vSphere in the SDDC: vCenter Converter, vSphere Replication & SRM
3 Chapter 2: Compute Resources & Cluster Management
2.1 vSphere High Availability (HA) Architecture 2.2 Distributed Resource Scheduler (DRS) & Resource Pools 2.3 vMotion & Enhanced vMotion Compatibility 2.4 Virtual Machine Advanced Compute Configuration 2.5 Fault Tolerance, Proactive HA & Advanced Cluster Options 2.6 vSphere Cluster Services (vCLS) & Retreat Mode 2.7 Migration Types: Cold Migration, Storage vMotion & Cross vCenter Export
4 Chapter 3: Storage Technologies & VMFS Datastores
3.1 Storage Access Protocols & Multipathing 3.2 VMFS Datastore Architecture & Management 3.3 Storage Policies (SPBM) & Virtual Volumes (vVols) 3.4 Storage DRS & Storage I/O Control 3.5 RDM, PMem, NVMe, NVMe-oF & iSER Use Cases
5 Chapter 4: VMware vSAN Architecture & Operations
4.1 vSAN Core Architecture & Disk Groups 4.2 vSAN Fault Domains & Stretched Clusters 4.3 vSAN Storage Policies & Data Protection 4.4 vSAN Maintenance, Health Checks & Monitoring
6 Chapter 5: Virtual Networking Architecture & Configuration
5.1 Standard Switches (vSS) vs Distributed Switches (vDS) 5.2 Port Group Policies & NIC Teaming 5.3 VLAN Configuration & Security Policies 5.4 Network I/O Control (NIOC) & TCP/IP Stacks
7 Chapter 6: Security, Identity & Access Control
6.1 vCenter Single Sign-On (SSO) & Identity Sources 6.2 Role-Based Access Control (RBAC) & Global Permissions 6.3 Virtual Machine Encryption & Key Management 6.4 ESXi Host Security & vSphere Trust Authority 6.5 vSphere Certificate Management 6.6 VM Firmware, Secure Boot, vTPM & Virtualization-Based Security
8 Chapter 7: Lifecycle Management & Host Configuration
7.1 vSphere Lifecycle Manager (vLCM) Cluster Images 7.2 Baseline-Based Lifecycle Management 7.3 Host Profiles & Cluster Quickstart 7.4 Content Libraries & Virtual Machine Deployment 7.5 ESXi Host Configuration: Time, Services, Product Locker & Boot Options 7.6 vCenter Lifecycle: Update Planner, VAMI Patching & Upgrades 7.7 Virtual Machine Snapshots & VM Creation Methods
9 Chapter 8: Monitoring, Performance Tuning & Troubleshooting
8.1 Performance Monitoring & Metrics 8.2 Command-Line Diagnostics & esxtop 8.3 Log Analysis & Diagnostic Data Collection 8.4 Troubleshooting Common Infrastructure Scenarios 8.5 Alarms & vCenter Appliance Health Monitoring
2.3 vMotion & Enhanced vMotion Compatibility
Key Takeaways Explain This Topic AI
vMotion copies memory in iterative pre-copy passes, slows fast-dirtying VMs with Stun During Page Send (SDPS) when needed, switches over during a brief stun (VMware targets under a second), and sends RARP frames so switches learn the VM's new port.
Each host needs a VMkernel adapter enabled for vMotion, optionally on the dedicated vMotion TCP/IP stack; a host runs up to 4 concurrent vMotions on 1 GbE and 8 on 10 GbE or faster.
Multi-NIC vMotion spreads one migration across several physical NICs: create one vMotion VMkernel adapter per NIC, each with a different active uplink and the other uplinks standby or unused.
Enhanced vMotion Compatibility (EVC) cluster baselines mask CPUID feature flags to the lowest common denominator, preventing CPU-related vMotion incompatibilities across hardware generations.
Per-VM EVC (vSphere 6.7 and later, hardware version 14+) stores the EVC mode with the VM, so it can move between clusters with different EVC settings as long as each destination host's CPU supports that mode.
Last updated: September 2026
vMotion & Enhanced vMotion Compatibility
VMware vSphere vMotion enables the live migration of active, powered-on virtual machines from one physical ESXi host to another with zero application downtime. When combined with Enhanced vMotion Compatibility (EVC), vMotion allows workloads to move freely across disparate server hardware generations within and between enterprise clusters.
vMotion Architectural Workflow & Migration Lifecycle
The vMotion engine transfers a virtual machine's active execution state—specifically its in-memory working set, device states, and virtual CPU thread contexts—over the network. The migration can be understood as seven phases: +--------------------------------------------------------------------------+
- | vMotion Execution Phases |
- +--------------------------------------------------------------------------+
- | Phase 1: Initialization & Pre-Flight Compatibility Verification |
- | Phase 2: Target Host Shadow VM Instantiation |
- | Phase 3: Initial Memory Pre-Copy (Base Memory Transfer) |
- | Phase 4: Iterative Dirty Page Tracking (Bitmap Memory Pre-Copy) |
- | Phase 5: Final Switchover & Sub-Second VM Stun (State Transfer) |
- | Phase 6: Shadow VM Activation & Physical Network RARP Broadcast |
- | Phase 7: Source VM Teardown & Resource Release |
- +--------------------------------------------------------------------------+
- Detailed Phase Breakdown
Initialization & Compatibility Check : vCenter Server verifies that the source and destination hosts share compatible networking (port groups or VLANs), datastore access, and CPU instruction sets.
Shadow VM Creation : The destination ESXi host instantiates an empty "shadow" virtual machine shell, reserving the necessary compute and memory footprint.
Initial Memory Pre-Copy : The source host begins transmitting the virtual machine's physical memory pages across the vMotion network to the target host. During this phase, the guest OS continues running and executing I/O operations normally.
Iterative Memory Pre-Copy & Dirty Page Tracking : As memory pages are transferred, the guest OS writes new data to RAM. ESXi uses an internal memory tracking mechanism (a dirty page bitmap) to track every modified page. In successive iterations, vMotion transfers only the dirty pages. If the rate of guest memory modification ("dirtying rate") exceeds the network transmission speed, ESXi uses Stun During Page Send (SDPS) , introduced in vSphere 5.0, to inject microsecond-scale pauses into the guest's vCPUs until the pre-copy converges.
Final Switchover & VM Stun : When the volume of remaining dirty pages can be transferred across the network in less than the target stun time (VMware targets a switchover under 1 second ), the source host briefly stuns (quiesces) the VM. It transfers the final dirty memory pages, CPU register states, and device contexts to the target host.
Resume on Destination & Reverse ARP : The target host un-stuns and resumes the virtual machine. Immediately upon activation, the target ESXi host generates a broadcast Reverse Address Resolution Protocol (RARP) frame on behalf of the VM's MAC address. Physical top-of-rack switches receive this RARP and immediately update their MAC address tables (CAM tables) to point to the new physical switch port, ensuring inbound network packets route to the new host without dropped connections.
Cleanup : The source host releases the VM's memory allocations and deletes the source VM instance.
vMotion Network Requirements & Maximums
- Specification 1 GbE Network 10 GbE / 25 GbE Network
- Recommended Minimum Link Speed Supported (Minimum) Recommended Standard
- Max Concurrent vMotions per Host 4 concurrent migrations 8 concurrent migrations
- Max Concurrent vMotions per Datastore 128 concurrent migrations 128 concurrent migrations
- Round-Trip Time (RTT) Latency Limit 150 ms (Long-Distance vMotion) 150 ms (Long-Distance vMotion)
- Dedicated TCP/IP Stack Recommended ( vMotion stack) Recommended ( vMotion stack)
- Dedicated vMotion TCP/IP Stack
vSphere provides a dedicated vMotion TCP/IP stack at the VMkernel layer. Using this stack isolates vMotion traffic from standard management networking. It features its own routing table, default gateway, and ARP table, preventing vMotion traffic from traversing management gateways or causing routing conflicts across layer-3 subnets.
Multi-NIC vMotion Architecture
A single vMotion migration stream cannot easily saturate multiple physical 10 GbE or 25 GbE uplinks due to single-stream TCP limitations. Multi-NIC vMotion solves this by establishing multiple concurrent TCP connections across separate physical network adapters.
Configuration Rules for Multi-NIC vMotion
To configure Multi-NIC vMotion correctly on a vSphere Standard Switch (VSS) or vSphere Distributed Switch (VDS):
Create two or more VMkernel interfaces (e.g., vmk1 and vmk2 ) and configure both with the vMotion service enabled.
Assign unique IP addresses within the same subnet (or across routed subnets if using the vMotion TCP/IP stack).
Configure explicit failover ordering on the virtual switch:
For vmk1 : Set vmnic1 as Active and vmnic2 as Standby (or Unused).
For vmk2 : Set vmnic2 as Active and vmnic1 as Standby (or Unused).
When a migration starts, vMotion opens parallel streams across all vMotion-enabled VMkernel adapters, so each additional adapter-and-uplink pair adds bandwidth.
- Enhanced vMotion Compatibility (EVC)
- The CPU Instruction Incompatibility Problem
When a virtual machine powers on, the guest operating system queries the physical processor's CPUID feature flags and utilizes available hardware instruction extensions (such as AVX, AVX2, AVX-512, BMI2, or AES-NI). If an administrator attempts to migrate this running VM to an older ESXi host lacking those specific CPU instruction sets, the guest OS would encounter illegal instruction faults and trigger an immediate kernel panic or crash.
Cluster-Wide EVC
Enhanced vMotion Compatibility (EVC) eliminates this barrier. Configured at the cluster level, EVC presents a standardized baseline CPU feature set to all virtual machines in the cluster:
ESXi intercepts CPUID queries from the guest OS and masks out advanced instruction sets supported by newer physical hosts, ensuring all VMs run at the cluster baseline.
A cluster can encompass multiple generations of processors from the same manufacturer (e.g., Intel Broadwell, Skylake, Cascade Lake, and Ice Lake).
Limitation : EVC cannot bridge between different processor vendors. Intel and AMD CPUs cannot be combined in the same EVC cluster.
Per-VM EVC
Introduced in vSphere 6.7, Per-VM EVC decouples the CPU compatibility baseline from the cluster object (the VM needs hardware version 14 or later):
The EVC baseline is configured directly on an individual virtual machine while powered off.
The EVC mode is saved in the VM's configuration, so it travels with the VM.
When the VM migrates to another cluster, another vCenter Server, or a VMware cloud, it keeps its CPU baseline, so the destination cluster does not need the same cluster-wide EVC mode. Each destination host's CPU must still support the VM's EVC mode.
- Feature Cluster-Wide EVC Per-VM EVC
- Configuration Level Cluster Settings Virtual Machine Settings (via UI or API)
- Persistence Boundary Host membership within cluster Encapsulated within VM .vmx configuration
Cross-Cluster Mobility Destination cluster must match or exceed baseline Can move between clusters with different EVC settings if the destination CPU supports the VM's mode
Power State Requirement Cluster property; VMs inherit on reboot VM must be powered off to configure or alter baseline
Advanced Cross vCenter vMotion (X-vMotion)
Cross vCenter vMotion (X-vMotion) enables live migration of virtual machines across independent vCenter Server instances without requiring them to share a common Single Sign-On (SSO) domain or Enhanced Linked Mode.
Operational Prerequisites
Workflow : Advanced Cross vCenter vMotion, introduced in vSphere 7.0 Update 1c, adds Import and Export workflows to the vSphere Client. You can migrate between vCenter instances in different SSO domains without Enhanced Linked Mode.
Network Latency : Maximum supported Round-Trip Time (RTT) between source and destination ESXi hosts is 150 ms .
Network Provisioning : Target port groups must be mapped, or layer-2 network stretch must exist to avoid IP address disconnects.
Disk Provisioning : If storage is not shared, X-vMotion performs a simultaneous Storage vMotion and compute vMotion over the network.