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

Cutover is the final step of a warm migration. XMS takes a last incremental sync to bring the target volume fully up to date, powers off the source VM, runs guest conversion against the target volume, and launches the migrated instance on Xloud. When cutover completes, the source VM is left powered off and the target instance is the authoritative copy.
Prerequisites
  • A warm migration job in Ready state (full sync completed and at least one successful incremental sync)
  • A maintenance window long enough for the final sync, guest conversion, and target boot — typically a few minutes for small workloads
  • Agreement from the workload owner that the source VM can be powered off

Lifecycle

PhaseWhat Happens
Final DeltaA last incremental sync transfers any blocks that changed since the previous sync.
Power Off SourceXMS issues a graceful shutdown to the source VM. If the guest does not respond in time, a hard power off is used.
Guest FixesVirtIO drivers are injected, the boot loader is repaired, and hypervisor-specific tooling is removed.
FinalizeThe target volume is marked bootable and attached to the target instance record.
Boot TargetThe target Xloud instance is launched from the migrated volume.
CompletedCutover is complete — the target instance is running on Xloud.

Trigger Cutover

Open the warm migration job

Navigate to Migration → Warm Migration and select the job you want to cut over. The job must be in Ready state.

Confirm the lag is acceptable

Check the Lag column. A low lag means the final delta sync will be quick. If the lag is high, trigger a Sync Now first and wait for it to finish before starting cutover.

Click Cutover

Click Cutover. A confirmation dialog summarizes what happens next:
  • Final incremental sync runs immediately
  • Source VM is powered off
  • Guest conversion runs against the target volume
  • Target Xloud instance is launched
Confirm to proceed. The job transitions to Cutting Over.

Watch live progress

The panel shows live progress for every phase. Events stream in real time — final delta bytes, source power off state, guest conversion steps, and target boot.
Job status reaches Completed and the target instance is visible in the Xloud Dashboard.

Validate the target

Click the link to the target instance, confirm it reaches an active power state, and proceed to post-migration validation.

What Happens to the Source VM

During Cutover

XMS issues a graceful shutdown to the source. If the guest does not respond within the configured timeout, a hard power off is used to keep the cutover window tight.

After Cutover

The source VM stays powered off in its source environment. XMS does not delete the source — decommission it manually only after you have validated the migrated workload on Xloud.
Do not power the source VM back on after cutover. The source and target share identity (hostname, MAC, disk UUIDs) and running both simultaneously can cause network and storage-level conflicts.

Cutover Window

The cutover window is the time between the start of the final delta sync and the target instance booting on Xloud. It determines how long the workload is unavailable. Typical contributions:
PhaseTypical Duration
Final delta syncSeconds to a few minutes — depends on churn since the last incremental
Source power offSeconds to a minute — graceful shutdown of the guest
Guest fixes30 seconds to a few minutes — VirtIO driver injection and boot loader repair
Finalize and bootUnder a minute — attach volume and launch target instance
To minimize the cutover window, run a manual Sync Now immediately before triggering cutover. This reduces the number of blocks the final delta has to transfer.

Rollback

If cutover fails at any phase before the target boots, XMS leaves the source VM powered off and the job in Failed state. You can:
  • Power the source VM back on manually — the source data is unchanged
  • Inspect the failure in the event stream and in Troubleshooting
  • Re-trigger cutover once the underlying issue is resolved
If the target instance has already booted and you need to roll back, treat the target as the authoritative copy and migrate back from Xloud to VMware separately — there is no in-place revert once the target is live.
A target instance that has booted on Xloud and accepted writes cannot be reverted to the source by XMS. Plan cutover timing so you have confidence in the migrated workload before releasing it to users.

Next Steps

Post-Migration Validation

Verify the migrated instance boots, networks, and behaves correctly

Troubleshooting

Diagnose failed cutovers, stuck guest conversion, and boot errors

Warm Migration

Review the warm migration lifecycle and sync mechanics