vMotion Network Calculator

Size vMotion bandwidth and estimate live-migration time from VM memory, dirty-page rate and concurrent migration limits.

About vMotion Network Calculator

vMotion copies memory iteratively: a full pass, then repeated passes for pages the guest dirtied, until the remaining delta is small enough to switch over in under a second. The dirty-page multiplier stands in for those extra passes, and because vSphere divides the link across concurrent migrations, raising concurrency shortens the wall clock for a whole host but lengthens each individual migration. Maintenance windows are planned against evacuation time, and a 1 GbE vMotion network running four concurrent migrations gives each one 175 Mbps — under the supported floor, which is how a routine patch night turns into an all-nighter.

Formula

vMotion Network

time = VM memory × dirty-page multiplier ÷ (link speed × share ÷ concurrent migrations); the evacuation window is ceil(VMs ÷ concurrent migrations) waves of that time.

dirty-page multiplier: Extra data re-sent because the guest keeps writing during pre-copy
per-migration bandwidth: Usable link speed divided across concurrent migrations
250 Mbps: vSphere's minimum bandwidth requirement per concurrent vMotion

Worked example

With the default values below, vMotion Network Calculator returns Time per Migration of 204.2. Change any input above and every figure here is recalculated in your browser.

Inputs used

Memory per VMaccepts 0.25–6,144 GiB: 32 GiB
vMotion network speedone of 1 GbE, 10 GbE, 25 GbE, 40 GbE, 100 GbE: 10 GbE
Share of the link available to vMotionaccepts 5–100 %: 70 %
Concurrent migrationsaccepts 1–16 migrations: 4 migrations
Dirty-page multiplieraccepts 1–4 x: 1.3 x
VMs to evacuateaccepts 1–2,000 VMs: 24 VMs

Results

Time per Migration: 204.2 s
Bandwidth per Migration: 1,750 Mbps
Concurrent Migrations Allowed: 8 migrations
Full Evacuation Window: 20m
Data Moved per Migration: 42 GiB
250 Mbps Minimum Check: Comfortably above the 250 Mbps per-migration floor

Step by step

1Values used
2vMotion Network
3Time per Migration= 204.2 s
4Bandwidth per Migration= 1,750 Mbps
5Concurrent Migrations Allowed= 8 migrations
6Full Evacuation Window= 20.42
7Data Moved per Migration= 44,667,659,878
8250 Mbps Minimum Check= Comfortably above the 250 Mbps per-migration floor

Assumptions and limits

The result is derived only from the 6 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax or compounding frequency into account.
Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is vMotion Network calculated?

time = VM memory × dirty-page multiplier ÷ (link speed × share ÷ concurrent migrations); the evacuation window is ceil(VMs ÷ concurrent migrations) waves of that time. vMotion copies memory iteratively: a full pass, then repeated passes for pages the guest dirtied, until the remaining delta is small enough to switch over in under a second. The dirty-page multiplier stands in for those extra passes, and because vSphere divides the link across concurrent migrations, raising concurrency shortens the wall clock for a whole host but lengthens each individual migration.

Why does vMotion Network matter?

Maintenance windows are planned against evacuation time, and a 1 GbE vMotion network running four concurrent migrations gives each one 175 Mbps — under the supported floor, which is how a routine patch night turns into an all-nighter.

What values do I need to enter?

This calculator takes 6 inputs: Memory per VM, vMotion network speed, Share of the link available to vMotion, Concurrent migrations, Dirty-page multiplier, VMs to evacuate. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why does vSphere cap concurrent migrations at 4 on 1 GbE and 8 on 10 GbE?

The cap exists to keep each migration above the 250 Mbps floor. Eight concurrent migrations on a 1 GbE link would leave 125 Mbps each, so the pre-copy phase would never converge on an active VM.