Cold Migration

Overview

Cold migration is the simplest way to move a workload from VMware to Xloud. The source VM is powered off, all disks are exported through the vSphere API, written into Xloud Block Storage volumes, converted for Xloud drivers, and the migrated instance is started in the target Xloud project. The source VM remains in the source environment (powered off) until you confirm the migration succeeded.

Prerequisites

A discovered workload that has passed preflight assessment
A target Xloud project with sufficient quota for the compute, memory, and volume footprint of the migrated VM
A target Xloud network that can host the migrated VM’s NICs
An acceptable maintenance window — the source VM will be powered off for the duration of the migration

Lifecycle

Stage	What Happens
Queued	The job is accepted and waits for an available worker slot
Export	Source VM is powered off; disks are streamed over the vSphere API
Inspect	Guest OS family, firmware, and disk layout are detected
Write Volume	A new Xloud Block Storage volume is created and disk data is written directly into it
Guest Fixes	VirtIO drivers are injected, the boot loader is repaired, and hypervisor-specific tooling is removed
Finalize	The volume is marked bootable, metadata is attached, and the target Xloud instance is prepared
Completed	The target instance is created and ready to launch

Submit a Cold Migration

Dashboard
CLI

Open the Migrations tab

Navigate to Migration → Migrations and click New Migration. Select Cold Migration and pick the source environment.

Select the workload

Pick one or more VMs from the discovered inventory. Each selected VM must have a Pass or Warn preflight verdict.

Choose target project and quota

Field	Description
Target Project	Xloud project to receive the migrated instance
Instance Name	Name in the target project (defaults to the source VM name)
Flavor	Xloud flavor that matches or exceeds the source vCPU and memory
Volume Type	Target storage tier for the migrated volumes
Availability Zone	Optional — pin the instance to a specific zone

Map networks

For each source NIC, pick a target Xloud network and subnet. You can optionally request the same MAC address on the target network, subject to network policy.

Save a network mapping as a reusable profile if you plan to migrate many VMs from the same source into the same target environment.

Review and submit

Review the job summary, estimated runtime, and target resources. Click Submit. The job enters Queued state and is picked up by the next available migration worker.

Watch live progress

The Migrations tab updates live with per-stage progress, bytes transferred, and an event stream. A completed job shows a link to the newly created Xloud instance.

Job status reaches Completed and the target instance is visible in the Xloud Dashboard.

# Submit a cold migration for a single VM
xms migration submit \
  --source prod-vcenter \
  --vm win-ser-2022 \
  --kind cold \
  --target-project infra \
  --flavor m1.large \
  --volume-type ssd \
  --network-map 'VM Network=internal-net'

# Watch live progress
xms migration events --job <job-id> --follow

# Inspect the result
xms migration show <job-id>

What Happens to the Source VM

During Migration

The source VM is powered off. All reads happen through the vSphere API, and the source disks are never written to — the migration is read-only on the source side.

After Migration

The source VM remains powered off in its source environment. XMS does not delete it — you choose when to decommission the source after you have validated the migrated instance on Xloud.

Do not power the source VM back on after cutover if the target instance has already booted on Xloud. The two VMs share identity (hostname, MAC, disk UUIDs) and running both simultaneously can cause network and storage-level conflicts.

Progress and Event Stream

Every cold migration publishes a stream of events that are visible live in the Migrations tab:

Event	When It Fires
`source.powered_off`	Source VM has reached `poweredOff`
`export.started`	Disk export has opened a session with the source
`export.progress`	Emitted periodically with bytes transferred
`write.started`	Target volume has been created and disk write has begun
`write.progress`	Emitted periodically during volume write
`guest_fixes.started`	VirtIO driver injection and boot loader repair have begun
`finalize.completed`	Target volume is bootable and attached to the target instance
`migration.completed`	Job is complete — target instance is ready

Next Steps

Post-Migration Validation

Verify the migrated instance boots and works as expected

Warm Migration

Use incremental sync for workloads that can’t tolerate a maintenance window

Troubleshooting

Diagnose stuck jobs and guest boot issues

Core Services

Other Services

Cold Migration

Overview

Lifecycle

Submit a Cold Migration

Open the Migrations tab

Select the workload

Choose target project and quota

Map networks

Review and submit

Watch live progress

What Happens to the Source VM

During Migration

After Migration

Progress and Event Stream

Next Steps

Post-Migration Validation

Warm Migration

Troubleshooting

​Overview

​Lifecycle

​Submit a Cold Migration

Open the Migrations tab

Select the workload

Choose target project and quota

Map networks

Review and submit

Watch live progress

​What Happens to the Source VM

During Migration

After Migration

​Progress and Event Stream

​Next Steps

Post-Migration Validation

Warm Migration

Troubleshooting

Overview

Lifecycle

Submit a Cold Migration

What Happens to the Source VM

Progress and Event Stream

Next Steps