VM Migration Time Calculator

Migration type:

Choose the path that matches your hypervisor migration job.

VM memory:

Use the memory size visible to the guest or hypervisor migration task.

Disk data to move:

Set 0 when storage is already shared or disk movement is outside this migration window.

Usable migration bandwidth:

Enter the measured or reserved bandwidth for this VM, not the interface line rate.

Mbps

Memory dirty rate:

Use hypervisor counters, migration logs, or a conservative workload estimate.

Mbps

Compression ratio:

A 1.2 ratio means the migration sends about 83% of the logical bytes.

Setup and validation time:

Include pre-check and post-check time that consumes the maintenance window.

min

Cutover overhead:

This is added to the final stop-copy time for the downtime estimate.

sec

Migration window:

Set 0 to skip window-fit checks.

Downtime target:

Use 0 when the downtime objective is unknown.

sec

Dirty-set stop threshold:

The model stops when the dirty set fits this threshold or the downtime budget.

MiB

{{ error }}

Workload name:

Use a hostname, VM name, or migration wave identifier.

Disk churn during copy:

A churn rate near the usable bandwidth can prevent disk copy catch-up.

Mbps

Parallel migrations sharing link:

Leave 1 when this VM has the full bandwidth reservation.

VMs

Pre-copy round limit:

Use a lower value when host policy forces quick evacuation; use a higher value for gentle convergence.

rounds

Schedule buffer:

Leave 0 for raw math; add buffer for production change planning.

Phase	Duration	Elapsed	Status	Basis	Copy
{{ row.phase }}	{{ row.duration }}	{{ row.elapsed }}	{{ row.status }}	{{ row.basis }}

Round	Data sent	Duration	Dirty set after round	Projected downtime	Decision	Copy
{{ row.round }}	{{ row.dataSent }}	{{ row.duration }}	{{ row.dirtyAfter }}	{{ row.projectedDowntime }}	{{ row.decision }}

Check	Status	Evidence	Action	Copy
{{ row.check }}	{{ row.status }}	{{ row.evidence }}	{{ row.action }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A VM migration plan usually fails in the margins: the link is slower than the interface label, a busy guest keeps changing memory while it is being copied, or a disk move takes longer than the maintenance window allows. The calendar appointment may say one hour, but the real question is how much state has to cross the migration path and how quickly that state keeps changing.

Live migration moves a running virtual machine by copying its memory and execution state to another host while the guest keeps working. Storage migration moves disk blocks from one datastore or storage path to another. A shared-storage live migration can avoid bulk disk copy because both hosts already see the same virtual disks, while a shared-nothing migration has to account for both memory movement and disk payload.

The most important terms are easy to mix up. Migration time is the full elapsed window consumed by checks, bulk copy, repeated catch-up work, the final pause, and any planning buffer. Downtime is only the paused part near cutover, when remaining dirty memory and device state are finished before the VM resumes. A migration can fit the total window and still violate an application downtime target.

Factors that change VM migration time
Planning factor	Why it changes the estimate
Memory footprint	Larger memory needs more pre-copy work before the VM can be stopped briefly for cutover.
Disk payload	Shared-nothing and storage-only moves are often dominated by disk bytes, not guest memory.
Usable bandwidth	The effective migration rate is the sustained share available after policy limits, storage bottlenecks, encryption cost, and concurrent migrations.
Dirty memory and disk churn	Changed pages or changed blocks may need to be recopied. If change rate approaches transfer rate, catch-up can stall.
Cutover rules	A tight pause target forces the final dirty set to be small; a loose target may allow fewer pre-copy rounds.

Two common mistakes skew early estimates. The first is using port speed instead of observed migration throughput; a 10 Gbps link rarely means one VM gets 10 Gbps for the whole move. The second is using provisioned disk size when only a smaller changed-block set will actually move, or doing the opposite and ignoring a full disk copy for a shared-nothing migration.

Compatibility and operational readiness remain separate checks. CPU features, device passthrough, snapshots, storage locks, network reachability, platform throttles, and application quiescing can decide whether a migration is allowed at all. Time estimation is still valuable because it turns those checks into a realistic runbook window and a separate pause budget.

How to Use This Tool:

Start with the migration path, then enter measured rates rather than optimistic hardware limits.

Set Migration type to Shared-nothing live migration, Live migration with shared storage, or Storage-only VM move. This decides whether memory, disk, or both are included.
Enter VM memory and Disk data to move with the right decimal or binary unit. Use the payload or changed-block amount that will actually cross the migration path.
Enter Usable migration bandwidth, Memory dirty rate, and Compression ratio. Use a compression ratio of 1.0 when compression is disabled or already reflected in measured throughput.
Add Setup and validation time, Cutover overhead, Migration window, and Downtime target so the result can separate total elapsed time from paused time.
Open Advanced when disk churn, concurrent migrations, pre-copy round limits, dirty-set stop threshold, or a schedule buffer materially affects the runbook.
Use the validation message when the summary says Check inputs. Bandwidth must be greater than zero, compression must be at least 1.0, parallel migrations must be at least 1, and the selected migration type needs a nonzero memory or disk amount.
Confirm that Migration Phases, Convergence Rounds, and Window Guidance agree before copying the estimate into a change plan. A result is ready to use only when the timing, downtime, and convergence messages tell the same story.

Interpreting Results:

The Migration window summary is the headline elapsed-time estimate. Confirm it against the final elapsed value in Migration Phases, then check Stopped copy for the downtime estimate. Those two numbers answer different questions: one is the change-window duration, and the other is the expected pause.

Convergence Rounds shows whether live memory copy is catching up. A healthy run normally shrinks the dirty set across rounds. A repeated large dirty set, round limit reached, or a high dirty-rate-to-link ratio means the final stopped phase can grow even when the total window looks acceptable.

VM migration result cues and follow-up actions
Result cue	Meaning	Follow-up
`ready to plan`	The modeled phases fit the entered window and downtime target.	Keep the measured bandwidth and dirty-rate evidence with the change record.
`window risk`	The elapsed estimate misses the migration window or downtime target.	Reduce the disk payload, reserve more bandwidth, stagger the wave, or increase the window.
`forced stop-copy`	Pre-copy hit the round limit before the dirty set met the stop budget.	Lower workload churn, raise bandwidth, allow more rounds, or schedule a quieter period.
`disk not converging`	Disk churn is greater than or equal to the usable disk-copy share of the link.	Quiesce writes, pre-seed storage, reduce parallel moves, or use a faster storage path.

Technical Details:

Migration timing is governed by transfer volume, transfer rate, and change rate. Memory and disk sizes are converted to bytes before calculation. Decimal units such as GB and TB use powers of 1000; binary units such as GiB and TiB use powers of 1024. Network rates entered in megabits per second are converted to bytes per second by dividing by 8.

Concurrent migrations reduce the per-VM share of bandwidth. Compression reduces the bytes that must traverse the link, but it does not remove the need to model churn: dirty memory and changed disk blocks can keep producing new transfer work while the migration is already in progress.

Formula Core:

The core equations below use B for bytes per second, C for compression ratio, P for parallel migrations, D for disk bytes, M for memory bytes, and W for write or dirty rate.

B_{vm} = \frac{B_{entered}}{P}

T_{disk} = \frac{D / C}{B_{vm} - (W_{disk} / C)}

T_{round} = \frac{M_{round} / C}{B_{vm}}

M_{next} = \min (M_{vm}, W_{mem} \times T_{round})

T_{downtime} = \frac{M_{final} / C}{B_{vm}} + T_{cutover}

T_{total} = T_{setup} + T_{disk} + \sum T_{round} + T_{downtime} + T_{buffer}

Disk copy converges only when the denominator in the disk equation is positive. Memory pre-copy starts with the full memory image, then each later round sends the dirty set created during the previous round. The live-copy loop can stop when the next dirty set fits either the dirty-set threshold or the remaining downtime copy budget, otherwise it stops at the configured round limit.

Migration modes and modeled phases
Migration type	Memory phase	Disk phase	Primary limiter
`Shared-nothing live migration`	Included	Included	Disk payload, dirty memory, disk churn, and per-VM bandwidth.
`Live migration with shared storage`	Included	Excluded	Dirty memory compared with available migration bandwidth.
`Storage-only VM move`	Excluded	Included	Disk payload, changed-block churn, and any shared-link contention.

For example, 64 GiB of memory over a true 1000 Mbps per-VM migration share has a first-round lower bound near 9.2 minutes before dirty pages are resent. If the memory dirty rate is 80 Mbps, the dirty-rate-to-link ratio is about 8%, so the second round is much smaller. If the dirty rate rises to 650 Mbps on a 500 Mbps share, the ratio is 130% and the dirty set cannot shrink under a pre-copy model.

Accuracy Notes:

The estimate is a planning model, not a hypervisor admission check or a guarantee of cutover behavior. Treat the result as a runbook input and validate it with platform counters, migration logs, and a representative test when the workload is important.

Use measured migration throughput, not nominal interface speed, when change approval depends on the estimate.
Keep dirty-rate and disk-churn inputs conservative for databases, message queues, batch jobs, and high-write filesystems.
Check CPU compatibility, storage visibility, snapshots, passthrough devices, host policy, and network reachability outside the time model.
Do not put sensitive hostnames or workload identifiers into saved reports unless those reports are handled like change-management records.

Worked Examples:

A shared-storage live migration with 64 GiB memory, 1000 Mbps usable bandwidth, 80 Mbps memory dirty rate, 5 setup minutes, 10 cutover seconds, and a 45 second downtime target produces a Migration window estimate near 15.1 min. Convergence Rounds reaches stop-copy target met in round 2, and Stopped copy is about 13.5 sec.

A shared-nothing migration with the same memory profile, 500 GiB of disk data, 50 Mbps disk churn, 8 setup minutes, 20 cutover seconds, and a 10% schedule buffer is dominated by Disk copy. The total estimate is about 1.72 hr, so Window Guidance flags the Migration window fit as missing a 1.5 hr window even though Downtime fit remains inside a 60 sec target.

A storage-only move of 250 GiB with 2000 Mbps reserved bandwidth and 2 parallel migrations gives each VM about 1000 Mbps. With a 1.25 compression ratio, 6 setup minutes, and a 15% schedule buffer, Migration Phases shows the total near 39.8 min and no live-memory Stopped copy phase.

A troubleshooting case starts with 32 GiB memory, 500 Mbps bandwidth, and 650 Mbps memory dirty rate. Convergence Rounds keeps sending roughly the full memory amount until round limit reached, and the summary badge becomes forced stop-copy. The modeled paused time is about 9.3 min, which misses a 30 sec downtime target even though the total elapsed time may still fit a one-hour change window.

FAQ:

Should disk data mean provisioned size or used size?

Use the amount that will actually move. For a full shared-nothing copy that may be the active disk payload; for a seeded or replicated move it may be only the remaining changed-block delta.

Why is downtime different from migration time?

Most disk and memory copy work can happen while the VM is still running. Downtime is the final stopped phase, plus cutover overhead, after live copy has done as much catch-up work as the settings allow.

What does not converging mean?

For memory, it means dirty pages are being produced too quickly for pre-copy to shrink the remaining set within the round limit. For disk, it means disk churn consumes the usable copy rate.

Why does parallel migration change the answer so much?

The bandwidth entry is divided by Parallel migrations sharing link. Two migrations sharing the same reservation give each VM half the modeled transfer rate, which can double copy time before other limits are considered.

Can this confirm that a destination host is safe to use?

No. The calculation checks timing, convergence, window fit, and downtime fit. CPU compatibility, storage access, network policy, snapshots, passthrough devices, and platform placement rules must be checked separately.

Glossary:

Cutover overhead: Paused-state time for device state, resume work, network updates, and operator confirmation outside the final dirty-memory copy.
Dirty rate: The rate at which a running VM changes memory pages that may need to be resent during live migration.
Disk churn: The rate at which disk blocks keep changing while a storage or shared-nothing migration is trying to copy them.
Pre-copy: A live migration phase where memory is copied in rounds while the VM continues to run.
Shared-nothing migration: A migration where the destination does not already share the VM storage, so disk data must also move.
Stopped copy: The final paused phase that transfers remaining dirty state and completes cutover.

References:

Migrating virtual machines, Red Hat Documentation.
Live Migration Overview, Microsoft Learn.
Dirty limit, QEMU Documentation.
Postcopy, QEMU Documentation.

VM Migration Time Calculator

Introduction:

How to Use This Tool:

Interpreting Results:

Technical Details:

Formula Core:

Accuracy Notes:

Worked Examples:

FAQ:

Glossary:

References: