Question
Which vMotion configuration minimizes VM stun duration for latency-sensitive apps?
Nia Dey
0 reputation · 28 Oct 2025, 11:19 UTC
33.1K views1
Loading…
0 reputation · 28 Oct 2025, 11:19 UTC
When migrating a powered-on virtual machine between ESXi hosts in a vSphere environment, the final memory synchronization phase involves a brief period where the VM is paused, known as the stun period. For small applications with strict latency requirements, this pause can potentially trigger application-level timeouts or disconnects.
The duration of this stun is influenced by the rate of memory page changes and the available bandwidth on the vMotion VMkernel network. While shared storage simplifies the process, the transition of the device state remains a critical point of uncertainty regarding perceived downtime.
To minimize VM stun duration, the most effective configuration is the implementation of Multi-NIC vMotion combined with 10GbE (or faster) networking and Jumbo Frames (MTU 9000). For environments supporting it, utilizing vMotion over RDMA (Remote Direct Memory Access) provides the lowest possible latency and CPU overhead during the memory transfer phase.
The "stun" occurs during the final synchronization phase when the VM is paused to transfer the remaining dirty memory pages and device state. This duration is primarily a function of the ratio between the VM's memory change rate (churn) and the available network throughput. If the network cannot evacuate dirty pages faster than the application creates them, the final stun window expands to ensure state consistency.
Assumptions: This guidance assumes a vSphere 7.0+ environment with shared storage. If using storage vMotion (shared-nothing), stun times are typically higher due to the additional disk mirroring phase.
To verify the impact of these changes, use esxtop on the source and destination hosts during a migration to monitor network throughput and CPU wait times. You can also review the vSphere Client 'Summary' tab for the specific VM to analyze the migration duration logs.
Missing Diagnostic Detail: To provide a more precise throughput recommendation, the average memory page change rate (MB/s) of the application during peak load is required.
Use comments to ask for clarification. Post a solution as an answer.
32,275 reputation · 28 Oct 2025, 18:54 UTC
A frequent assumption is that EVC settings directly influence vMotion stun duration. EVC's actual role is to mask CPU feature sets across host generations to enable migration; it does not add processing or network overhead to the dirty‑page sync or pause. The stun window is primarily determined by how quickly the vMotion network can evacuate dirty pages relative to the application's memory-change rate. For latency‑sensitive apps, a practical way to assess stun risk is tracking the %VMWAIT counter in esxtop during a migration test; sustained %VMWAIT above expected levels signals network contention. Providing the vMotion VMkernel path with 2‑3× the observed peak dirty‑page throughput provides the headroom needed to keep stun reliably under 1 ms.
vsphere