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
XMS speaks to a source hypervisor API, the platform storage and compute APIs, and the running target instance at different phases of a migration. Each conversation uses a specific port and needs a network path that can sustain the traffic. This page lists the ports and paths operators need to open.Quick Reference
| Source | Destination | Port | Purpose | Direction |
|---|---|---|---|---|
| XMS | vCenter or ESXi | 443 | vSphere API and disk transport negotiation | Egress |
| XMS | ESXi host | 902 | Disk transport data stream | Egress |
| XMS | Xloud Identity | 5000 | Token validation | Egress |
| XMS | Xloud Block Storage | 8776 | Volume create and write | Egress |
| XMS | Xloud Compute | 8774 | Instance create and attach | Egress |
| XMS | Xloud Networking | 9696 | Network mapping validation | Egress |
| Dashboard / CLI | XMS API | 443 | User-facing API | Egress |
Port numbers shown are the defaults. Your deployment may publish XMS and
the platform services behind a virtual IP or a TLS-terminating load
balancer — adjust accordingly.
XMS ↔ Source
vSphere API (port 443)
XMS opens a vSphere API session against the vCenter or ESXi endpoint to:- Authenticate the stored credential
- Walk the inventory during discovery
- Read VM configuration, disk metadata, and CBT state during preflight
- Negotiate a disk transport session before each read
Disk Transport Data Stream (port 902)
After negotiation, the actual disk data is streamed between XMS and the ESXi host that owns the source VM’s datastore. This connection is NFC (Network File Copy) on port 902 by default.Bandwidth and Latency
- The disk transport session is bandwidth-bound — a full sync of a large VM will saturate the available path during the export phase
- Incremental warm syncs read only dirty blocks, so the steady-state bandwidth cost is proportional to source churn, not total disk size
- Round-trip latency over 50 ms noticeably slows the full sync phase — keep XMS and the source on the same LAN or metro link where possible
XMS ↔ Xloud Services
XMS acts as an Xloud tenant on behalf of every migration. It makes standard API calls against:- Identity for token validation on every inbound and outbound request
- Block Storage to create target volumes and write disk data into them
- Compute to create the target instance and attach the volume
- Networking to validate the network mapping chosen at submit time
Operator Access
Operators reach the XMS API through the platform’s public endpoint — the same endpoint used for the rest of the Xloud Dashboard and CLI. The Migration panel is served by the existing Dashboard web service, and thexms CLI calls the XMS API over the public endpoint.
Egress From the Target Instance
After a migration completes, the target Xloud instance is a normal compute instance. XMS does not inject any agent or open any extra port on the target guest — standard Xloud network security group rules apply for egress, ingress, and management access.Firewall Change Checklist
Open egress to ESXi hosts for disk transport
Allow TCP/902 from XMS to every ESXi host that may own source VM storage.
Verify internal Xloud service traffic
No change required — XMS communicates with Identity, Block Storage,
Compute, and Networking over the existing platform service network.
Next Steps
Prerequisites
Platform and project prerequisites for a new source
Source Credentials
Build the service account and role
Capacity Planning
Size XMS for concurrent migrations and multi-wave campaigns