Documentation Index
Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt
Use this file to discover all available pages before exploring further.
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.
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.
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.
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