The questions start before the first disk is copied. Which worker can reach the datastore? Will the guest boot with VirtIO drivers? What happens to its static IP? And if a pass fails, can you see why?

01 / Components

Disk data goes through the workers.

The control plane is written in Go. It handles inventory, migration plans, scheduling, permissions, audit records and destination API calls. Workers run as VMs inside vSphere. They read the source disks and write to the selected KVM storage. Disk data does not pass through the control plane.

CoordinateControl planePlans / state / audit
MovevSphere workersHotAdd / CBT / conversion
WriteKVM storageNFS / RBD / LINSTOR
AdoptDestinationPlatform integration

Writing the disks and registering the VM are separate jobs. Adding a destination integration shouldn't require rewriting the source-read path.

V2K Migrate warm migration plan showing lifecycle, topology and fleet progress
A warm migration plan in the current V2K Migrate interface. All infrastructure and workload data shown here is synthetic.

02 / Discovery

Check the VM before creating a plan.

Inventory pulls information from vCenter: firmware, guest details, disks, NICs, MAC addresses, clusters and datastores. Saved IP inspection results are shown alongside them. You can filter by topology and inspect a VM before adding it to a plan.

The offline scale test used 50,928 visible synthetic VMs across four vCenters, with six clusters and sixteen datastores per site. This checks the inventory and browser behaviour. It is not a test against a real 50,000-VM vCenter.

03 / Source transport

Why HotAdd, and what it requires.

V2K Migrate uses VMware VDDK SCSI HotAdd. A snapshot-backed VMDK is attached to a Linux worker VM and read through the ESXi storage stack. The reads use the datastore I/O path, not the NBD/NBDSSL network transport through NFC.

NBD can be simpler to deploy. HotAdd needs the worker in the right place: its ESXi host must have access to the source datastore, and the worker must have free disk attachment slots. V2K Migrate checks placement and the negotiated transport. If HotAdd isn't available, the operation fails rather than quietly falling back to NBD.

DecisionWhat it means
Strict HotAdd transportNo silent fallback to NBD when HotAdd cannot be used.
Datastore-aware placementOnly workers with access to the source datastore are eligible.
Separate VM and disk limitsA VM with several disks needs several attachment slots, even though it is one migration task.
Direct target writesThe control plane doesn't relay the disk data.

04 / Warm migration

Copy first, then catch up with CBT.

The base copy runs first. Changed Block Tracking then identifies the changes for subsequent delta passes. Each pass keeps its status, throughput, timing and results. Cutover can be manual, scheduled or triggered by the plan's policy.

There is still downtime at cutover: shut down the source, apply the final delta, then finish the destination VM. The earlier passes reduce how much data is left to copy during that window. This is not live migration.

05 / Guest preparation

The guest needs preparation for KVM.

Offline inspection reads the guest disks to identify the OS, firmware, disk layout and network configuration. Conversion then prepares supported guests for KVM. It doesn't decide which worker to use, where to write the disks or when to cut over; those decisions belong to the migration plan.

Windows network configuration is part of this work. The workflow can preserve source MAC addresses and static IPv4 settings when the inspection results are clear enough. If they aren't, that needs operator attention, not a guess.

06 / Destination

Writing the disks doesn't create the VM.

The storage layer includes NFS/QCOW2, direct Ceph RBD and LINSTOR/DRBD through a KVM-side gateway. These paths have different client and verification requirements. Having a storage writer does not mean every destination integration supports that backend.

After transfer and guest preparation, the destination integration creates and configures the VM. CloudStack was the first integration. Proxmox is implemented for NFS/QCOW2, with a controlled warm/CBT migration validated end to end. Ceph and LINSTOR support for Proxmox is still planned.

07 / Checks and cleanup

Before the run, and when something goes wrong.

Preflight checks the source VM, worker placement, available capacity, storage and destination compatibility before migration starts. During a run, the UI shows VM progress, pass history and warnings.

  • Permissions: administrator, operator and viewer roles have different access.
  • Audit: state-changing actions are recorded.
  • Cleanup: termination paths handle migration snapshots and HotAdded disks.
  • Diagnostics: pass results, errors and reports remain available for review.
  • Support bundles: diagnostic exports go through redaction.

08 / Current status

What has been implemented and tested.

Implemented and lab-testedStrict HotAdd, cold migration, warm CBT passes and controlled cutover.
Backend-specific validationNFS/QCOW2, Ceph RBD, LINSTOR/DRBD and the first CloudStack workflow, each within its documented test scope.
Proxmox on NFS/QCOW2Implemented, with controlled warm/CBT end-to-end validation. Proxmox Ceph and LINSTOR support is planned.
Not claimedZero downtime, every guest OS or the same verification coverage on every backend.

These are scoped test results, not a claim that every combination works. Further test results and implementation changes will get their own posts here. For current release information and licensing, see the product site.