Skip to main content

​
Overview

nxtMove 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

Port numbers shown are the defaults. Your deployment may publish nxtMove and the platform services behind a virtual IP or a TLS-terminating load balancer — adjust accordingly.

​
nxtMove ↔ Source

​
vSphere API (port 443)

nxtMove 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
This is a TCP-over-TLS conversation and can go through an HTTPS-aware firewall or proxy.

​
Disk Transport Data Stream (port 902)

After negotiation, the actual disk data is streamed between nxtMove and the ESXi host that owns the source VM’s datastore. This connection is NFC (Network File Copy) on port 902 by default.
For a vCenter-managed source, open port 902 to every ESXi host that may own the source VM — not just to the vCenter. VMs can move between hosts, so the transport session may hit any host in the cluster.

​
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 nxtMove and the source on the same LAN or metro link where possible

​
nxtMove ↔ NxtSight Services

nxtMove acts as an NxtSight 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
These calls happen over the platform’s internal service network. Operators who run nxtMove alongside the rest of the NxtSight platform typically do not need to make any new firewall changes for this path.

​
Operator Access

Operators reach the nxtMove API through the platform’s public endpoint — the same endpoint used for the rest of the NxtSight Dashboard and CLI. The Migration panel is served by the existing Dashboard web service, and the nxtMove CLI calls the nxtMove API over the public endpoint.

​
Egress From the Target Instance

After a migration completes, the target NxtSight instance is a normal compute instance. nxtMove does not inject any agent or open any extra port on the target guest — standard NxtSight network security group rules apply for egress, ingress, and management access.

​
Firewall Change Checklist

Open egress to vSphere API

Allow TCP/443 from nxtMove to the vCenter or ESXi endpoint.

Open egress to ESXi hosts for disk transport

Allow TCP/902 from nxtMove to every ESXi host that may own source VM storage.

Verify internal NxtSight service traffic

No change required — nxtMove communicates with Identity, Block Storage, Compute, and Networking over the existing platform service network.

Verify target instance traffic

No change required — standard NxtSight security group rules apply to the migrated instance.
For vCenter-managed sources, ask the vSphere admin which ESXi hosts currently own the source VM’s datastores. Open port 902 to all of them — VMs can vMotion between hosts, so the transport session may target any host.

​
Next Steps

Prerequisites

Platform and project prerequisites for a new source

Source Credentials

Build the service account and role

Capacity Planning

Size nxtMove for concurrent migrations and multi-wave campaigns