kubevirt-vm-migration-platform

ADR 003: Cold migration before warm migration

• Status: Accepted

Context

Warm migration copies disks while the source runs, using VM snapshots and VMware Changed Block Tracking (CBT), then performs a short cutover. It needs API write access to the source (snapshots, CBT). Our source is free standalone ESXi, where API use is unsupported and may be read-only, and there is no vCenter. Our first workload is one small nginx VM where minutes of downtime are acceptable.

Decision

The first real migration is cold: power off the source, copy and convert the disk, import with CDI, start on KubeVirt. Warm migration is theory and industry reference only (as implemented by MTV). We do not design a custom warm-migration engine.

Consequences

• Simpler, consistent disk images; no snapshot or CBT dependency.
• Downtime = copy + convert + import + boot. It will be measured and recorded in the migration status.
• The CRD keeps spec.strategy.type with Cold only, reserving Warm.
• Revisit only with a licensed vSphere (or vCenter) source and a demonstrated need.
• Clarification (Stage 0 refinement): warm migration (precopy, CBT, cutover) remains reference and study work only, documented from MTV as an industry reference. No warm-migration code, CRD phases or controller logic will be designed until this ADR is superseded.

Evidence

MTV 2.11 planning guide (precopy snapshots every 60 min by default, 28-CBT-snapshot limit, RAM not migrated at cutover); Broadcom KB 399823 (free-edition API limits).