Skip to content
Calcrivo

vMotion Network Calculator

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

Inputs

GiB
%

vMotion usually shares an uplink with management and VM traffic.

migrations

vSphere allows 4 per host on 1 GbE and 8 on 10 GbE or faster.

x

Pre-copy re-sends pages the guest changes mid-migration; busy VMs cost more.

VMs

Time per Migration

204.2s

Bandwidth per Migration

1,750Mbps

Concurrent Migrations Allowed

8migrations

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

  1. Values used

    Memory per VM = 32 GiB; vMotion network speed = 10 GbE; Share of the link available to vMotion = 70 %; Concurrent migrations = 4 migrations; Dirty-page multiplier = 1.30 x; VMs to evacuate = 24 VMs

  2. 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.

  3. Time per Migration

    = 204.2 s

  4. Bandwidth per Migration

    = 1,750 Mbps

  5. Concurrent Migrations Allowed

    = 8 migrations

  6. Full Evacuation Window

    = 20.42

  7. Data Moved per Migration

    = 44,667,659,878

  8. 250 Mbps Minimum Check

    = Comfortably above the 250 Mbps per-migration floor

How it works

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

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.

You might also need