How to identify vMotion stun time for a vMotion
search cancel

How to identify vMotion stun time for a vMotion

book

Article ID: 436882

calendar_today

Updated On:

Products

VMware Cloud Foundation VMware vCenter Server 8.0 VMware vCenter Server 6.0 VMware vCenter Server 5.0 VMware vSphere ESX 5.x VMware vSphere ESX 6.x VMware vSphere ESX 7.x VMware vSphere ESX 8.x VMware vSphere ESXi

Issue/Introduction

This article describes how to identify vMotion stun time for a vMotion by correlating log entries across multiple log sources on both the source and destination ESXi hosts.

Environment

VMware vSphere 
VMware vSphere Foundation

Cause

When a migration begins, the first iteration copies the entire memory contents of the virtual machine to the destination host. Each subsequent iteration copies only the memory pages that were modified (dirty page) during the preceding iteration. This process continues until the remaining set of dirty pages is small enough that it can be transferred within the 500 ms switchover time goal. At that point, the virtual machine is stunned (guest execution is suspended) and the final pages are sent. Once the destination host acknowledges receipt, the VM resumes execution there and the stun ends.

Resolution

In order to identify the vMotion stun time, follow the below steps:

  • Step 1: Identify the Migration ID

Locate the migration ID for the vMotion operation in the vmware.log file in the VM's home directory. Search for the string migration id:

#cat vmware.log | grep "migration id"
2026-04-14T15:38:20.200Z| vmx| I120: Migrate_Open: Restoring from <10.0.0.2> with migration id 1446046703473901
2026-04-14T15:38:20.244Z| vmx| I120: Migrate_Open: Restoring from <10.0.0.2> with migration id 1446046703473901

Note: Use this migration ID to search for correlated entries across all relevant log files.

  • Step 2: Identify the Switchover Phase in vmkernel.log

The vmkernel.log on both the source and destination ESXi hosts contains the most detailed record of the switchover phase. These entries confirm when pre-copy stops and when the destination acknowledges receipt of all memory pages.

Source ESXi — vmkernel.log:

2026-04-14T15:38:20.160Z cpu0:151370)VMotion: 4650: 1446046703473901 S: Stopping pre-copy: only 1296 pages left to send, which can be sent within the switchover time goal of 0.500 seconds (network bandwidth ~145.404 MB/s, 101088% t2d)
2026-04-14T15:38:20.213Z cpu1:151421)VMotionSend: 4156: 1446046703473901 S: Sent all modified pages to destination (network bandwidth ~355.662 MB/s)

Destination ESXi — vmkernel.log:

2026-04-14T15:38:20.272Z cpu0:151065)VMotion: 5994: 1446046703473901 D: Received all changed pages.
2026-04-14T15:38:20.275Z cpu0:151065)VMotion: 5773: 1446046703473901 D: Resume handshake successful
  • Step 3: Read the Recorded Downtime Value

Search the destination host's log for the migration ID and the string downtime. The vMotion downtime value is recorded explicitly in:

  • vpxa.log on ESXi 6.0 and later
  • hostd.log on ESXi 5.x
2026-04-14T15:38:20.471Z verbose vpxa[64732B70] [Originator@6876 sub=vpxaMoVMotion opID=5473CC5D-00006321-7b-ce-29-ab] [MIGRATE] (1446046703473901) vmotion result has downtime value 89339

Note: The downtime value is reported in microseconds (µs). In this example, 89339 µs equals approximately 89 milliseconds (0.09 seconds).

  • Step 4: Correlate Using vmware.log on Both Hosts

During vMotion, a new vmware.log is created on the destination host and the existing log on the source is rotated. You must therefore compare the current vmware.log (destination) against the latest rotated vmware.log (source) to bracket the stun window. The stun time is written to the vmware.log file in the VM home directory:

2026-04-14T15:38:18.854Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 188405 us

The time is in microseconds (us) so the stun time for this snapshot was 188ms or 0,18 seconds. You can also determine the time by comparing the destroy event and the unstun:

Source ESXi — rotated vmware.log:

2026-04-14T15:38:18.854Z| vmx| I120: MigrateSetState: Transitioning from state 2 to 3.
2026-04-14T15:38:20.177Z| vcpu-0| I120: MigrateSetState: Transitioning from state 3 to 4.
2026-04-14T15:38:20.177Z| vcpu-0| I120: Migrate: Preparing to suspend.
2026-04-14T15:38:20.177Z| vcpu-0| I120: Migrate: VM starting stun, waiting 100 seconds for go/no-go message.
2026-04-14T15:38:20.179Z| vcpu-0| I120: Destroying virtual dev for scsi0:0 vscsi=8194

Destination ESXi — current vmware.log:

2026-04-14T15:38:20.244Z| vmx| I120: Migrate_Open: Restoring from <10.0.0.2> with migration id 1446046703473901
2026-04-14T15:38:20.265Z| vcpu-0| W110: Restoring VMM

The elapsed time between the "VM starting stun" entry on the source and the "Restoring VMM" entry on the destination represents the total stun duration — approximately 90 milliseconds in this example.

 

 

Additional Information

Both vmDowntime and checkpoint_unstun  counters measure the vMotion stun time, but they measure it from different perspectives.

checkpoint_unstun is the stopwatch running inside the VM itself, it starts the moment the guest is frozen and stops the moment it starts running again on the destination.

vmDowntime is the stopwatch running at the management layer (vpxa), it starts at the same moment but stops only once vpxa on the destination has received, processed, and recorded the result. So it includes the pure stun time plus the overhead of all the VM management tasks happening around it.

Powered by Wolken Software