Short answer: vSphere vMotion live-migrates a running VM between ESXi hosts by copying its memory and device state over a dedicated vMotion VMkernel network while the VM keeps running, then switching execution to the destination host in a brief stun. It needs a vMotion license, compatible CPUs (or EVC), storage both hosts can see (or Storage vMotion), and a vMotion network with at least 250 Mbps per concurrent migration and up to 150 ms round-trip time. vSphere 8 can also notify applications before a migration.
What vMotion transfers: cold data and hot data
KB 342209 splits a migration into two kinds of traffic:
| Data | Content | Protocol | VMkernel port used |
|---|---|---|---|
| Cold | VM files and disks (when storage also moves) | NFC, TLS-encrypted by default | Provisioning vmk if configured, otherwise management |
| Hot | Memory and device state of the running VM | vMotion protocol | vMotion vmk |
For a compute-only vMotion on shared storage only hot data moves. For vMotion without shared storage (compute plus storage in one operation) both move, so a provisioning VMkernel adapter keeps disk copy traffic off the management network.
How a live migration runs
- Compatibility check: vCenter validates CPU compatibility, network and storage visibility, and device backing (connected ISO images or physical devices can block the move).
- Memory pre-copy: the destination host creates a shadow VM and memory is copied while the VM keeps running. Pages the guest changes during the copy are tracked and sent again in further passes.
- Switch-over: once the remaining dirty memory is small enough, the VM is briefly stunned, the last pages and device state are sent, and execution resumes on the destination.
- Network notification: the destination host announces the VM’s MAC addresses on the physical network so switches update their tables, and the source VM is cleaned up.
The busier the guest writes to memory, the more pre-copy passes are needed. Bandwidth on the vMotion network therefore directly affects how long a migration takes and how short the stun is.
vMotion requirements for ESXi hosts
| Area | Requirement |
|---|---|
| License | Each host licensed for vMotion; long-distance vMotion needs a license that covers it |
| CPU | Same or compatible CPU family, or an EVC baseline on the cluster |
| Storage | Shared storage visible to both hosts, or vMotion without shared storage |
| Bandwidth | At least 250 Mbps dedicated per concurrent vMotion session |
| Latency | Round-trip time up to 150 ms between hosts |
| VMkernel | vMotion-enabled vmk on both hosts; use the vMotion TCP/IP stack to route vMotion across L3 subnets |
| VM network | The VM port group must exist at L2 on the destination |
Sources: Host Configuration for vSphere vMotion and KB 342209. To check which VMkernel adapters carry vMotion on a host, esxcli network ip interface tag get -i vmk1 shows the tags per adapter; more commands are in my esxcli cheat sheet for ESXi 8.
vMotion application notifications in vSphere 8
Some applications (clustered databases, trading, telco and real-time workloads) do not tolerate even a sub-second stun without preparation. Starting with vSphere 8.0, ESXi can tell an application inside the guest when a vMotion is about to start and when it has finished, so the application can drain work, fail over a role, or delay the migration. See vSphere vMotion Notifications for Latency Sensitive Applications.
- The VM needs hardware version 20 or later and current VMware Tools (see the VMware Tools versions and builds), which delivers the notifications to the guest.
- Enable it per VM with the advanced setting
vmOpNotificationToAppEnabled = TRUE(VM Options > Advanced > Edit Configuration). - The application registers through VMware Tools and must acknowledge the start event; vMotion pauses until it does or until the timeout expires.
- The host timeout
vmOpNotificationToApp.Timeout(seconds, set via the vSphere API) defaults to 0: notifications are sent but migrations are not delayed. If both host and VM timeouts are set, the smaller one wins.
Keep the timeout short. A long delay also holds up DRS balancing and host maintenance mode, which is exactly when you need vMotion to finish.
Troubleshooting slow or failing vMotion
- Test the vMotion path with
vmkping -I vmkX -S vmotion <dest-vmotion-IP>when using the vMotion TCP/IP stack; add-d -s 8972to validate jumbo frames end to end. - A migration stuck on the storage phase usually points to the provisioning/management network, not the vMotion vmk.
- CPU compatibility errors mean the cluster needs an EVC baseline or the VM needs a power cycle to pick one up.
- On ESX 9.1, a host with three or more 25/100 GbE vMotion uplinks can crash with a PSOD in
vmotionRecvH. See ESX 9.1 vMotion PSOD (KB 455306) for the stream helper workaround.
