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

Before a new source can be registered or a new migration can run, the operator must satisfy a small number of platform-side, project-side, and source-side prerequisites. This page lists them in the order you should check them.

​
Platform Prerequisites

XMS is enabled on the Xloud platform

The Migration panel must be visible in the Xloud Dashboard and the xms CLI subcommand must be installed on operator workstations. If neither is available, XMS is not enabled on the deployment — contact Xloud support.

Identity service is healthy

XMS validates every API call against the platform identity service. If identity is unhealthy, source registration and job submission will fail. Confirm the platform health dashboard reports identity as reachable.

Block Storage and Compute are healthy

XMS writes migrated data through block storage and launches target instances through compute. Both must be healthy before any migration can run.

​
Project Prerequisites

Each target Xloud project that will receive migrated workloads needs:
RequirementWhy
Project exists and is activeXMS writes volumes and instances into an existing project — it does not create new projects
Quota for compute, memory, and volume footprintQuota is checked at submit time against the flavor and volume type selected
Volume type that matches the chosen storage tierThe operator must publish at least one volume type in the project; users pick one per migration
Target networks and subnetsEvery source NIC must map to a target network — the target networks must already exist in the project
User role with migration permissionUsers submitting migrations need a role that allows them to use the Migration panel in that project
For multi-wave campaigns, create a dedicated target project per wave. This keeps quota accounting simple and isolates waves from each other.

​
Source Environment Prerequisites

​
VMware vCenter

RequirementDetail
Supported vSphere versionvSphere 6.x, 7.x, or 8.x. Newer versions are supported as the transport library is refreshed
Reachable endpointXMS must be able to reach the vCenter endpoint on the configured port (default 443)
Service accountA dedicated vSphere account for XMS — see Source Credentials
Dedicated role at datacenter scopeCreate a vSphere role with the permissions listed in Source Credentials and assign it to the service account at the datacenter level

​
Standalone ESXi

Standalone ESXi is supported for lab, edge, and small-site migrations. The same transport library and pipeline apply — the only differences are:
  • Endpoint is the host address instead of a vCenter
  • Username is typically root or a local ESXi user
  • Datacenter is auto-detected as ha-datacenter

​
Guest-Side Requirements

RequirementWhy
VMware Tools installed (recommended)Exposes guest OS, hostname, and IP to discovery. Not a migration blocker when absent
Supported guest OSGuest must be in the Xloud guest catalog — see Preflight Assessment
Clean boot loaderXMS repairs drivers and the boot loader for platform-specific changes, but it does not fix a pre-existing broken boot loader
CBT enabled (warm only)Warm migration requires Changed Block Tracking on the source

​
Operator Access

The operator installing or maintaining XMS typically needs:
  • Administrative role on the Xloud platform (for installing, updating, and scaling XMS)
  • Read or admin role on every target project that will receive migrations
  • Credentials to register source environments (either shared service accounts or per-source accounts)
  • Access to platform monitoring to track XMS health

​
Pre-Onboarding Checklist

Use this checklist before onboarding a new source:
  • Identity service reachable and healthy
  • Block storage reachable and healthy
  • Compute reachable and healthy
  • XMS visible in the Xloud Dashboard
  • xms CLI installed and authenticated
  • Target project exists in the correct domain
  • Compute quota covers the expected wave footprint
  • Volume quota covers the expected wave footprint (+20% buffer)
  • Volume type published for the intended storage tier
  • Target networks and subnets exist
  • Users who will submit migrations have the right role
  • vSphere endpoint reachable from XMS
  • Service account created with the recommended role
  • Role assigned at the datacenter scope
  • TLS fingerprint or CA chain available if TLS verification is required
  • CBT enabled on every VM in the warm migration wave

​
Next Steps

Source Credentials

Build the service account and role for XMS

Network Ports

Open the right ports between XMS, source, and target

Register Source

Add the source to XMS once prerequisites are met