Picture a busy restaurant kitchen at full service. A chef is halfway through a dozen orders at one station when the oven behind them starts to fail. Stopping would mean cold food and angry diners. So a second chef quietly sets up an identical station next to the first, moves over every pan and every half-cooked dish, and at the exact right second the first chef lifts their hands and the second takes over the same spoon mid-stir. The diners never notice a thing.
That handover is vMotion. The dish is your running virtual machine, the station is the physical ESXi host, and the swap happens so fast that the application inside the VM, and the people using it, see nothing. vMotion is VMware name for live migration: moving a running VM from one host to another while it keeps serving traffic. No reboot, no shutdown, no maintenance window emailed to users at 2am.
What vMotion actually moves, and what it leaves alone
This is the point most beginners get wrong, so get it right early. A classic vMotion moves the compute state of the VM only: its memory (RAM), its CPU registers, and its in-flight network and device state. It does not move the virtual disk. The VMDK file stays exactly where it is, on a shared datastore that both the source host and the destination host can already see.
Back to the kitchen: the second chef does not carry the fridge across the room. The ingredients (your data on disk) are already in a shared pantry both stations use. Only the live cooking in progress (the memory) has to move. That is why classic vMotion needs shared storage. Both hosts plug into the same SAN or NFS share, so the moment the VM resumes on the new host, its disk is right there.
The trick: moving live memory without anyone noticing
The pre-copy rounds
Here is the clever part. The VM has, say, 8GB of RAM and it is busy. You cannot freeze it, copy 8GB, and unfreeze, that would be a long outage. Instead vMotion copies the memory in rounds while the VM keeps running. Round one copies all 8GB. But during that copy the VM kept working and changed some pages. So vMotion keeps a bitmap, a simple map of which memory pages got dirty, and round two resends just those. The VM is still changing pages, but fewer of them, so round three is smaller again. Each pass shrinks the gap.
The switchover, and the 100-second rule
Once the leftover set of dirty pages is tiny, vMotion does the handover. It briefly quiesces the VM (a stun lasting a fraction of a second), copies that last little bitmap plus the CPU state, and resumes the VM on the destination host. The network and storage paths follow, and the VM carries on. Users typically see one dropped ping at most.
Now the real-world detail you only learn by doing this. If that final switchover cannot complete in time, vMotion gives up rather than risk the VM. The error reads that the migration has exceeded the maximum switchover time of 100 seconds. The cause is almost always a VM dirtying memory faster than the vMotion network can ship it, often a very busy database on a slow or shared 1GbE link. The good news: the VM stays safely on the source host, untouched. The fix is a faster, dedicated vMotion network, or migrating during a quieter period. I have watched a junior panic at that message thinking they broke production. They did not. vMotion failing safe is the feature working as designed.
What vMotion needs before it will run
| Requirement | Why it is needed | Fresher note |
|---|---|---|
| Shared storage | Disk does not move, so both hosts must already see the VMDK | SAN, iSCSI or NFS reachable by both hosts |
| vMotion VMkernel port | A network path tagged for the memory copy | Tick the vMotion service on a VMkernel adapter |
| CPU compatibility | Destination must support the CPU features the VM is using | Enable EVC on the cluster (see below) |
| vMotion license | The feature is licensed, not free on every edition | Available from vSphere Standard upward |
| Fast network | Sets how many migrations run at once and how fast | 10GbE strongly preferred over 1GbE |
CPU compatibility and EVC
A running VM is using specific CPU instructions exposed by the host it started on. If you try to move it to a host with an older or different CPU that lacks those instructions, the VM could crash on arrival. So vMotion refuses, with a validation error saying the target host does not support the virtual machine current hardware requirements. Enhanced vMotion Compatibility (EVC) solves this. You set a cluster EVC baseline to the lowest common CPU generation, and every host then presents the same masked feature set, so any VM can move to any host. One catch worth knowing: EVC needs Intel-only or AMD-only clusters. You cannot mix Intel and AMD hosts and vMotion between them.
Gotcha
You can raise a cluster EVC baseline with VMs running, but lowering it (the common case, to admit an older host) needs the affected VMs to be powered off or freshly migrated in. People discover this at the worst moment, when a new host will not accept VMs and they cannot drop the baseline without an outage. Plan EVC before you grow the cluster, not after.
vMotion is not the only kind of move
Freshers mix these up constantly, so here is the clean split. Plain vMotion moves compute between hosts. Storage vMotion moves the disk between datastores while the VM stays on its host, useful when you retire old storage. And since vSphere 6 you can do both at once, moving compute and disk together, which means you no longer strictly need shared storage for a live move (the disk is copied too, it is just slower). In the modern interface you pick this under Migrate as change compute resource, change storage, or both.
| Type | What moves | Shared storage? | Typical use |
|---|---|---|---|
| vMotion | Memory + CPU state | Yes (classic) | Host maintenance, load balancing |
| Storage vMotion | Virtual disk files | No | Retiring or rebalancing storage |
| Both at once | Memory + CPU + disk | Not required | Moving between clusters or sites |
My take: turn on EVC before you think you need it
The common advice, and a lot of older documentation, says enable EVC only when you have mixed CPU generations. I disagree, and I tell every team I mentor the same thing. Enable cluster EVC at a sensible baseline from day one, even when all your hosts are identical and brand new. The reason is simple. Hardware refreshes happen on someone else timeline, not yours. Two years from now you will add a newer host to that cluster, and if EVC was never enabled you cannot turn it on without powering off running VMs to bring them down to the baseline. Set it once at the start, when the cluster is empty and nothing is running, and every future migration just works. The five minutes you spend at build time saves you a planned outage later. That is a trade I will take every single time.
Worked example: evacuating a host
You have 10 VMs on a host that needs a firmware patch. You put the host into maintenance mode and vSphere uses vMotion to evacuate all 10 to other hosts in the cluster, then you patch and reboot with zero user impact. How fast? vCenter gives each host a migration cost budget of 8. Over a 10GbE vMotion network each vMotion costs 1, so up to 8 VMs migrate at the same time and the host empties in a couple of waves. Over a 1GbE network each vMotion costs 4, so only 2 run concurrently and the same evacuation crawls.
That single number, 8 versus 2 concurrent, is the honest reason senior engineers insist on 10GbE for vMotion. It is not about one VM moving faster. It is about how quickly you can clear a whole host on a bad night.
Real interview question
A running VM needs to move to another host for maintenance with no downtime. Walk me through what happens.
A strong answer names vMotion, then shows you understand the mechanism: memory is pre-copied in rounds while the VM keeps running, a bitmap tracks pages that change so each round resends only the dirty ones, then a brief stun handles the final switchover and the VM resumes on the destination. Mention the requirements (shared storage so the disk is already reachable, a vMotion VMkernel port, CPU compatibility via EVC). Score bonus points by adding that if the switchover cannot finish it aborts safely rather than risk the VM, and that DRS automates all of this when a host enters maintenance mode. That last line tells the interviewer you have seen it run, not just read about it.
Try it yourself
You can do this free at home with nested virtualization. In VMware Workstation, build two nested ESXi hosts, add both to a single vCenter cluster, and present one shared datastore over iSCSI or NFS that both hosts can see. Put a tiny test VM on that datastore. Then right-click the VM, choose Migrate, pick change compute resource only, and send it to the other host while watching the task progress.
How to check you got it right: from a third machine, ping the VM continuously during the migration. If vMotion worked you should see zero or at most one dropped reply, and the Host column in vCenter flips to the second host. If it fails with a CPU error, enable EVC on the cluster at the lowest baseline and try again. Watching that single dropped ping is the moment vMotion stops being theory.
FAQ
Does vMotion really cause zero downtime?
Effectively yes, for the user. There is a sub-second stun during the final switchover, which usually shows up as one dropped ping at most. It is not zero in the laws-of-physics sense, but it is zero in the sense that matters: no logged-in user, web request, or running service notices.
Do I always need shared storage?
For classic vMotion, yes, because only memory and CPU move and the disk has to already be reachable by both hosts. Since vSphere 6 you can migrate without shared storage by copying the disk too, but that is slower and is really a combined move rather than plain vMotion.
Is vMotion the same as High Availability?
No, and this trips up a lot of freshers. vMotion is a planned, graceful move of a healthy running VM with no downtime. HA is for unplanned host failures: when a host crashes, HA restarts its VMs on surviving hosts, which does mean a short outage while they boot. Part 10 covers HA in full.
Why did my vMotion fail with a CPU error?
The destination host CPU lacks a feature the VM was using from the source CPU. Enable EVC on the cluster so all hosts present the same baseline feature set, then retry. Remember EVC is Intel-only or AMD-only, never mixed.
How many vMotions can run at the same time?
Up to 8 per host on a 10GbE vMotion network. On 1GbE the per-migration cost is higher, so only about 2 run concurrently. The host migration budget is a fixed 8, and network speed decides how much each move spends from it.
References
- Broadcom vSphere docs: Limits on Simultaneous Migrations
- Broadcom KB: vMotion exceeds the maximum switchover time of 100 seconds
- Broadcom KB: VMware EVC and CPU Compatibility FAQ
About The Author
DrJha