Skip to main content

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

Warm migration moves a workload from VMware to Xloud while the source VM continues to run. XMS takes a snapshot on the source, copies the full disk contents into a target Xloud Block Storage volume, and then replicates only the blocks that change on the source between syncs. When you trigger cutover, XMS replicates the final delta, powers the source off, runs guest conversion, and starts the target instance on Xloud — typically within minutes.
Prerequisites
  • A discovered workload that has passed preflight assessment
  • Changed Block Tracking (CBT) available on the source host
  • A target Xloud project with enough quota for the compute, memory, and volume footprint of the migrated VM
  • A stable network path between the migration service and the source environment that can sustain the full sync and incremental syncs

Lifecycle

PhaseMeaning
InitializingXMS enables CBT on the source if needed and records a change tracking baseline
Full SyncThe entire disk contents are copied to the target volume. Source VM keeps running the whole time.
ReadyInitial copy is complete. The job sits idle between scheduled syncs.
SyncingAn incremental sync is in progress — only blocks changed since the last baseline are read and applied
Cutting OverFinal delta sync, source power off, guest conversion, and target boot
CompletedTarget instance is running on Xloud

Submit a Warm Migration

Start a new migration

Navigate to Migration → Migrations and click New Migration. Select Warm Migration as the migration type and pick the source environment.

Pick source workload

Select the VM from the discovered inventory. Only VMs with a Pass or Warn preflight verdict are eligible.

Configure target

FieldDescription
Target ProjectXloud project that will host the migrated instance
Instance NameName the target instance will use after cutover
FlavorXloud flavor to match or exceed the source shape
Volume TypeStorage tier for the target volume (chosen once, used for every sync)
Availability ZoneOptional — pin the target instance to a zone

Map networks and set sync schedule

Map every source NIC to a target Xloud network and subnet. Choose a sync cadence:
CadenceTypical Use
ManualYou trigger each incremental sync explicitly
Every 15 minSmall, steady-state workloads
HourlyMedium workloads with predictable churn
DailyLarge workloads or low-churn archives
You can change the cadence at any time. Scheduling sync only controls how often new syncs start — it does not affect cutover.

Start full sync

Click Start Full Sync. XMS takes the baseline snapshot on the source, starts streaming disk data, and writes it into the target volume. The panel shows live progress — bytes read, bytes written, and estimated completion time.

Monitor ready state

When the full sync completes, the job transitions to Ready. From here, you can let the scheduler drive incrementals or trigger Sync Now manually.The Last Sync and Lag columns in the job list show how far behind the target is from the source.
Job status reaches Ready and per-sync lag stays within your tolerance.

How Incremental Sync Works

XMS uses vSphere Changed Block Tracking (CBT) to read only the blocks that have changed since the previous sync. Each sync runs through the same disk transport library used for the full sync, so the data path is identical — the only difference is that incremental syncs read the change map first and then stream only the dirty regions. Because every write targets the same offsets on the same Xloud Block Storage volume, there is no intermediate copy and the target volume is always a byte-for-byte current replica of the source at the time of the last sync.

Ready, Waiting for Cutover

Once the full sync has completed, the job stays in Ready state indefinitely. You can:
  • Let the scheduler run incrementals on the cadence you configured
  • Trigger Sync Now manually to force an incremental at any time
  • Pause the job to stop incrementals without losing progress
  • Proceed to cutover when you are ready to switch the workload to Xloud
The job retains CBT baselines as long as it is active. If you pause a warm migration for an extended period, re-enable CBT tracking and run a fresh sync before cutover to keep the delta small.

Sync Metrics

Each warm migration exposes live sync metrics in the Warm Migration tab:
MetricDescription
Last SyncTimestamp of the most recent completed sync
LagTime elapsed since the last successful sync
Bytes (Full)Total bytes read during the initial full sync
Bytes (Incr)Total bytes transferred across all incremental syncs so far
Sync CountNumber of successful incremental syncs performed
RateCurrent sync throughput (bytes/s during active sync)

Next Steps

Cutover

Execute the final sync and switch the workload to Xloud

Post-Migration Validation

Verify the migrated instance boots and behaves correctly

Troubleshooting

Diagnose stalled syncs, CBT resets, and connectivity errors