Why vMotion fails under live workload
Live migration of virtual machines looks like one command, but underneath it are several parallel streams: copying memory state, transferring disks, reconfiguring the network, and switching to the target host.
While they fit within the allotted window, the migration proceeds unnoticed. A VM migration failure begins where at least one stream cannot keep up with the load.
The first cause is data desynchronization. Memory is transferred page by page, and after synchronization starts, changed pages are copied again, and then again.
If the application writes faster than the channel can transfer, the round does not close: the hypervisor restarts synchronization up to the limit, after which it rolls back the migration — the VM remains on the source host, and the maintenance window has already shifted.
The second is the storage bottleneck. Different volumes, partition types, block size, and cache produce unpredictable speed: with Storage vMotion, data pours slower than planned, and disks with direct attachment cannot be migrated at all.
An overloaded channel between sites adds its own effect — migration traffic shares bandwidth with replication and backup, and the estimated time multiplies.
The third is the lack of resource headroom, which turns risk into service downtime during migration: without CPU and memory reservation on the target host, tested switching, and a rollback plan, any delay stretches into hours. We break down how this is addressed — from workload profile to migration dry run on a copy.
What migration without service downtime provides
The essence of migration without service downtime is that a running VM moves between hosts without shutting down: memory is copied to the target host, changed pages are caught up by repeated passes, and switchover takes fractions of a second.
Connections that fall into this pause reconnect by timeout rather than break with an error. The class of tasks "shut down, migrate, power on" leaves the maintenance plan.
Hence the main effect — reducing the maintenance window.
Hypervisor upgrades, hardware replacement, load rebalancing, and disk migration between datastores run on live systems: a node is put into maintenance mode, VMs move across the cluster, and the work no longer requires nighttime downtime.
Storage vMotion does the same with disks — the volume changes under a running system, without disconnecting and re-registering.
The class of failures associated with manual switchover is also removed. When migration is done manually — service stop, volume disconnection, rescan, registration on a new host, power-on, editing load balancer records — any error turns a planned window into an incident.
In live migration there is no room for error: if migration does not converge, the VM remains on the source host and continues serving requests.
The actual pause is fractions of a second instead of tens of minutes, and there is no longer any need to coordinate nighttime work with the business.
We verify service continuity on a pilot group: measure real unavailability, observe behavior under load, and only then migrate the rest.
Comparison of modes: vMotion and Storage vMotion
The live migration mode is chosen based on what exactly moves: compute node, storage, or both components at once.
In VMware vMotion, a running VM changes host, while its disks remain on shared storage — downtime is measured in seconds, and duration depends on connectivity between nodes, not disk size.
Storage vMotion solves the opposite task: VM files move to another datastore, while the VM itself remains on the current host. Migration time here is proportional to data volume and throughput between arrays.
| Option | When it fits | Limitations |
|---|---|---|
| vMotion | Need to offload a node, free it for maintenance, or balance cluster load; storage remains the same | Requires shared storage accessible to both hosts and compatible CPU instruction sets within cluster boundaries |
| Storage vMotion | Migration of VM storage: array replacement, decommissioning old equipment, moving disks to another tier | Requires free space on the target datastore and throughput headroom; large snapshots and disks in direct data transfer mode lengthen the operation |
| Both modes in sequence | Migration to another node and another datastore at the same time, including to another site or another cluster | The longest operation: requirements for network, compatibility, and free space add up; load headroom is needed |
Before choosing a mode, we check what most often breaks migration: disk snapshots, their connection mode, datastore types on both ends, and CPU compatibility.
This allows us to separate in advance VMs that will migrate without downtime from those that will have to be migrated separately.
Migration stages: from audit to handover
The order of work is fixed: facts first, then switchover. Infrastructure migration stages are structured so that each step gives a verifiable result, and the intermediate state can be rolled back — this is what distinguishes planned migration from emergency migration.
- Pre-migration audit. Inventory of VMs, guest OSes, disks, networks, and dependencies between services. Separately — compatibility with the target cluster and the storage workload profile during peak hours: it sets the allowable maintenance window.
- VM migration plan. We mark what moves via live vMotion without service downtime and what requires short downtime — changing disk format, drivers, or controller. We fix network mappings and group order.
- Site preparation. Datastores, pools, placement policies, permissions, replication schedules, backups. We check whether channel throughput is sufficient for disk transfer, not just for the switchover itself.
- Dry run. We migrate two or three copies from different groups and take control measurements: switchover time, I/O latency, storage load. Based on the measurements, we refine the scheme and window length.
- Main wave. Groups proceed in the specified order; after each, we check service availability, logs, and copies.
- Post-migration validation. Compare measurements with baseline; keep sources powered off but ready to start: this is the rollback plan.
- Handover. Access, diagrams, maintenance regulations, and return instructions for the on-call shift.
Documents and diagrams you keep
Migration ends not with the moment of switchover to another host, but with a set of infrastructure documentation that allows operating and developing it without the person who made the changes.
Below is what we hand over along with access: the list covers daily operations, the next migration, and incident analysis.
- Service dependency map. What is connected to what: calls to databases, message brokers, file storage, external systems. We collect it from configurations and network logs, not from administrator memory — during migration it immediately shows what cannot be shut down at the same time.
- Virtual infrastructure diagram. Clusters, hosts, datastores, network segments, failure points, CPU, memory, and disk headroom. With it, a new engineer understands the topology in an hour rather than a week of questions.
- Migration regulations. Step-by-step migration procedure: what we check before switchover, which metrics we consider signs of success, under what conditions we return to the source host, and how long it takes.
- Recovery regulations. Target recovery time and recovery point for each service, startup order, responsible persons, incident closure criterion.
- Access policies. Roles, service accounts, permissions at the cluster, datastore, and guest system levels, secret rotation rules, and procedure for granting access to new employees.
- Inventory and backup. Resources of each VM, backup schedule, storage locations, date of last restore verification from backup.
When a new contractor or your engineer opens these files, infrastructure handover does not turn into a back-and-forth of questions.
We write documents for your environment — with real host, datastore, and access group names, and before handover we go through the list with the team and correct anything that remains unclear.
Case: cluster migration without service downtime
A cluster of several dozen virtual machines was maintained manually. Planned migrations were done only in night windows: each with service downtime of forty to sixty minutes and an on-call engineer at the monitor.
There were six to eight such windows per month, and an error in migration order meant that some VMs came up with incorrect network settings and had to be fixed in the morning, on live users.
What was changed
Maintenance was moved to native VMware tools: running VMs are migrated between hosts on the fly via vMotion, disk volumes are migrated separately from compute — migration stopped being an event with downtime.
The order of operations was fixed in a regulation: first compatibility check at the level of CPU instruction sets and drivers, then compute migration, then storage, and only after that — putting freed hosts into maintenance.
Resource distribution rules were configured separately so that after migration the load would not fall on a single host.
What changed as a result
Night windows as a separate process disappeared: routine work runs during business hours, the number of planned downtimes decreased from six to eight per month to zero, and the freed time of on-call engineers went to infrastructure development.
Recovery time after a host failure decreased from several hours of manual troubleshooting to tens of minutes — VMs come up on a standby node according to a pre-written scenario.
Cluster migration now takes one business day instead of a series of night shifts, and the service was never shut down.
What to do if vMotion does not proceed on current storage
Most often live migration fails not because of hypervisor failure, but because there is no common reference point between the sides.
Four things are checked: whether one datastore is visible to both clusters, whether volume types match, whether CPU capabilities are reduced to a common set, and whether there are open snapshots and passthrough devices. Any of these details blocks migration before it starts, and the error shows only the consequence.
If hosts are in the same cluster, and what needs to be changed is the storage medium, not the compute node, this is a Storage vMotion task: disks move between datastores on the fly, without stopping the guest system.
The only limitation is throughput between arrays: with a weak array, migrations queue up and time out.
When there is no common point at all — different clusters, sites, no shared volume — it is done without rebuilding the infrastructure.
A "bridge" datastore accessible to both sides allows volumes to be migrated in parts: first the base, with a snapshot taken, then the delta, and the chain is assembled at the receiving end.
The number of simultaneous migrations is limited manually; otherwise the replication channel becomes congested.
If this does not work either, the guest level is used: replication by the system itself or cold migration — the VM is shut down, volumes are copied, and it is brought up in the new location. The cold path is predictable and during peak hours turns out to be faster than fighting timeouts.
On VMware and compatible platforms, we first take a compatibility map: which volumes are visible to whom, which instruction sets match, and where the channel bottleneck is. This way migration fits into the maintenance window without rebuilding the entire storage.
Common doubts before live migration
Before vMotion live migration, the same set of doubts arises: what will happen to the service if migration breaks, whether VMs will have to be shut down, and how databases will behave under load.
Below is a breakdown of the objections we hear most often, including clusters with shared storage and systems that have not been updated for a long time.
What happens if migration breaks in the middle?
The VM remains on the source host: until migration completes, the state is fixed by a return point, and if the connection breaks, guest systems continue to run where they were running. We verify rollback on a test group before migrating the rest.
Do virtual machines have to be shut down?
No. During live migration, memory and CPU state are transferred on the fly, and short unavailability is possible only at the moment of switchover. We measure its duration in advance rather than promising it in words.
How are databases and clusters migrated?
We migrate nodes one at a time, monitoring quorum and replication: the cluster must retain majority votes at every step. We switch write-intensive databases to a gentler synchronization mode and migrate them last.
What to do with legacy platforms?
Guest systems on old branches often do not support live migration — we update or rebuild them in advance. This lengthens preparation but removes a class of failures that would otherwise surface during the work.
Let's discuss your migration scenario
To order virtual machine migration, no formal document is needed — what administrators already have is enough: inventory exports, network diagrams, correspondence on maintenance windows.
From this set, we assemble a wave plan and say where switchover will take place without service downtime and where a window will be required.
- Fleet composition: number of VMs, operating systems, disk volume and type, snapshots, templates, VMs with shared cluster disks.
- Site layout: addressing, network segmentation, routing rules between environments, storage availability on both sides.
- Availability requirements for each service: allowable downtime duration, hours when switchover is prohibited, peak load periods.
- Critical services and connections between VMs: what comes up first, what holds locks and shared volumes, where startup order is strict.
- Current cluster and storage settings: datastore types, placement policies, limits on the number of concurrent tasks.
- Rollback conditions: until what point it is possible to return to the source site and whether there are enough resources there while cluster migration is underway.
Some items from the list may be missing — that is fine; we collect some data ourselves during the assessment. Describe the task and send what you have: we will come back with an estimate, wave breakdown, checkpoints after each, and rollback scenarios.
This way turnkey infrastructure migration gets measurable acceptance criteria, not a promise to "do it carefully." Let's discuss migration using the specific numbers of your fleet.