SeamlessMigrate

TOOL · THE PLANNING MODEL IN YOUR BROWSER

VM migration downtime calculator

Estimate how long a VM is down when it moves from OpenStack or VMware to RHOSO 18.0 or a community OpenStack cloud, for each strategy. The calculator runs the planning model of the Seamless Migrate control plane, with its default parameters, in your browser.

Try the local demo View on GitHub (opens in a new tab)
Strategies
Cold, warm, storage handover, VMware cold, VMware warm
Inputs
Disks, used space, link, write rate, shared storage, CBT
Defaults
125 MiB/s link, 2 MiB/s of writes, 500 MiB/s scan per disk
200 GiB VM
11m 20s warm, 20m 53s cold
Accuracy goal
Within ±30 % for 80 % of migrations, once calibrated

Estimate your VM downtime

Start from an example

Source
Disks
200 GiB
60 %

120 GiB of data

Link per migration
2 MiB/s

How fast the running VM changes its disks

Tune assumptions & change window

Use measured throughput, not the link's advertised speed. These settings affect this estimate only.

Network cut-over is a Technology Preview. Hook timeouts add to downtime; DNS cache expiry stays separate. Scan settings apply to OpenStack warm only. Extent tracking on main is planned for 0.5.0 and is not modeled here.

Seamless picks

11m 20s

of downtime with warm

Least downtime of the eligible strategies. That is 9m 33s less than a cold copy.

Within your 15m downtime target. Estimated, not guaranteed.

  • Cold copy

    cold

    20m 53s

    Stop, copy the used data over SSH, boot on the destination.

  • WarmPicked

    warm

    11m 20s

    Copy while running; after the stop, scan disks and transfer the final delta.

  • Storage handover

    storage_handover

    4m 20s

    Needs both clouds on the same Ceph cluster or NetApp ONTAP SVM.

Where the 11m 20s go with warm

Stop
1m
Snapshot, scan
7m 20s
Create
1m
Boot
2m

Pre-copy + downtime

42m 52s

Excludes approval and window wait

DNS cache expiry tail

0s

Separate from VM downtime

Data sent while the source keeps running

  1. Pass 1
    16m 53s
    120 GiB
  2. Pass 2
    7m 20s
    2.0 GiB
  3. Pass 3
    7m 20s
    879 MiB

Before the window: 3 passes in 31m 32s while the VM keeps running, then a final delta of 879 MiB.

Warm cutover takes the longer of a disk scan and the final delta transfer, plus fixed overhead. A faster scan or link helps when that step is the bottleneck.

Planning estimate for the 0.4.0-rc.1 scan-based model, assuming provider, disk and network pre-flight checks pass. Current assumptions: 500 MiB/s scan per disk stream, 4 disks in parallel, a 1 GiB convergence threshold and at most 5 passes. In a real plan, the first delta pass replaces the write and scan rates with measured ones. Read the performance model (opens in a new tab)

How the estimate is computed

Downtime runs from the moment the VM stops to its verified boot on the destination. Every strategy pays the same fixed steps: 60 s to shut the VM down, 60 s to create the server on the destination and 120 s to boot and verify it. What differs is the middle:

  • Cold: a 30 s snapshot, then the used data over the link: used space divided by the link speed.
  • Warm: pre-copy passes run while the VM serves traffic, each moving what the guest wrote during the one before. They repeat until a pass moves less than 1 GiB, or 5 passes ran. At cutover the final pass costs a 30 s snapshot plus the longer of the final delta's transfer and a read of the disks: the largest disk at 500 MiB/s, up to 4 disks in parallel.
  • Storage handover: 20 s per volume to unmanage it at the source and manage it at the destination. No data moves.
  • VMware cold: the used data over the link, then 300 s of virt-v2v conversion.
  • VMware warm: Changed Block Tracking passes while the VM runs; at cutover the final CBT delta moves and an in-place conversion takes 120 s.

Open Tune assumptions & change window to set measured scan speed, parallel disk streams, boot and verification time, and your downtime target. Post-create hook budgets extend the outage; DNS TTL describes how long clients may cache the old address and is shown separately.

Among the strategies a VM is eligible for, the least downtime wins. When two are within 10 % or 60 s of each other, the simpler one does: cold, then storage handover, then warm; VMware cold before VMware warm.

From estimate to measurement

The control plane starts from these defaults and recalibrates each VM's change rate and scan throughput after its first delta pass. The goal is an estimate within ±30 % of the actual downtime for at least 80 % of migrations once calibrated.

In the reference lab, warm VMs whose scan term is up to 330 s, for example a largest disk up to 100 GiB and 400 GiB in total, are expected to cut over in 10 minutes or less at p90; storage handovers in 6 minutes or less whatever the size. The full model is in the performance document.

FAQ

The model, answered.

What planners ask before they trust a number.

Why does warm downtime still grow with the disk size?

Because the final pass reads the disks to find the changed chunks: the scan of the largest disk at 500 MiB/s, about 3.4 minutes per 100 GiB. Release 0.5.0 plans to take that scan out of the final pass for Ceph RBD volumes, with changed-extent tracking as a Technology Preview.

When is a cold copy faster than a warm migration?

When little of the disk is used. A warm cutover scans the whole disk at 500 MiB/s, while a cold copy moves only the used data at the link speed, so at 125 MiB/s warm wins once more than about a quarter of the disk is in use.

What does the estimate include?

The time from the moment the VM stops to its verified boot on the destination: shutdown, the final copy, scan, handover or conversion, creating the server, booting and checking it. In the control plane, a plan's post_create hooks add their timeouts, and a DNS swap shows the record's TTL apart, as a tail after the downtime. It doesn't include the wait for a change window or a free cutover slot.

Is this the same model the control plane uses?

It models the 0.4.0-rc.1 scan-based path and minimum-downtime selection. Tune scan throughput, parallel disks, boot time and post-create hook budgets; DNS TTL stays separate. The real planner also checks capabilities and recalibrates measured rates. Changed-extent tracking under development for 0.5.0 is not included here.

MORE GUIDES

GET STARTED

Big possibilities.
First, a small pilot.

The demo runs every phase, from pre-copy to cutover, verification and rollback, against simulated clouds on your laptop. No OpenStack needed to try it.

Get the code (opens in a new tab)Read the design document (opens in a new tab)

Docker on a Linux server, or Colima on a Mac

$ git clone https://github.com/imransetiadi/seamless-vms-migration$ cd seamless-vms-migration# macOS only: not needed on Linux$ make seamless-colima-up$ scripts/compose-init.sh# simulated clouds, every phase$ make seamless-demo

Open the local demo (opens in a new tab)Sign in at /login with the admin token compose-init.sh printed. Podman works too: SEAMLESS_ENGINE=podman.