Skip to main content

​
Overview

XMS is a service inside the Xloud platform. It has a control plane that exposes the user-facing APIs and a pool of migration workers that execute the actual disk transport and guest conversion work. Both run alongside the rest of Xloud and integrate with the platform’s identity, storage, compute, and networking services.

​
Component Map

​
Workload Data Flow

​
Cold Migration

  1. Worker opens a disk transport session against the source via vSphere API
  2. Worker creates an empty target volume through Xloud Block Storage
  3. Disk data is streamed from the source and written into the target volume
  4. Guest conversion runs against the target volume
  5. The target instance is created and attached to the target volume

​
Warm Migration

  1. Worker takes a baseline snapshot on the source
  2. Full sync copies every block into the target volume
  3. Between syncs, the job sits idle in the Ready state
  4. Each incremental sync reads only the blocks that changed since the last baseline and writes them to the same offsets in the target volume
  5. At cutover, a final incremental sync and guest conversion run before the target instance is launched

​
Disk Transport Libraries

XMS uses the vSphere storage APIs and a disk transport library to read source VM disks efficiently. The library version is selected to match the source vSphere version and is an operator-managed component of the XMS deployment.
The transport library is the same code path for cold migrations, warm full syncs, and warm incremental syncs — only the set of blocks read differs between the three cases.

​
Integration with Xloud Services

Because migrated volumes and instances are native Xloud objects, the standard Xloud tooling — quotas, volume types, availability zones, security groups, snapshots, backups — applies automatically.

​
Multi-Source, Multi-Project

A single XMS deployment can:
  • Register multiple source environments (one or more vCenters, standalone ESXi hosts)
  • Run concurrent migration jobs across different sources
  • Target different Xloud projects for different migrations
Project scoping is enforced at the API layer using the caller’s identity token — users only see migrations for projects they are authorized to access.

​
Next Steps

Prerequisites

Platform, project, quota, and identity prerequisites

Network Ports

Which ports must be reachable between XMS, sources, and targets

Capacity Planning

Sizing XMS for concurrent migrations and multi-wave campaigns