Nutanix Move

Overview

Nutanix Move is a free migration tool that moves virtual machines between hypervisors with minimal downtime. It is deployed as an appliance, registers source and target environments as providers (VMware vSphere, Microsoft Hyper-V, Nutanix AHV, AWS and Azure), and organises the work into migration plans. A plan names a set of VMs, a source provider and a target, and runs through a lifecycle: validate the plan, prepare the guests, seed data while the source VM keeps running, then cut over during a short window. Move reports readiness and per-VM progress throughout.

The ReadyWorks connector talks to the Move appliance’s v2 REST API. It posts the connection’s username and password to /move/v2/users/login as a spec.username and spec.password body, reads the JWT from the Status.Token node of the response, and presents it as Authorization: Bearer on all subsequent calls. The inbound jobs then read plans, providers, workloads and appliance configuration into their own staging tables in the estate. Every job carries a retry policy of five attempts, five seconds apart, with a three hundred second API timeout.

In a ReadyWorks context this connector is about tracking a live migration programme. The inbound jobs tell you which plans exist, which VMs sit inside each plan, what state each of those VMs is in, and what the source environments actually contain. That lets you reconcile the migration plan against the estate of record, spot VMs that belong in a wave but were never added to a plan, report wave progress from the real appliance state rather than from a spreadsheet, and tie migration status back to the applications and owners already held in ReadyWorks.

Direction: the connector is bidirectional, and its outbound side is materially different from most connectors in this library. The eight outbound templates drive the migration itself rather than writing records back into Move. They create and delete migration plans, run readiness checks, prepare guest VMs, start a plan and perform per-VM actions such as cutover. In effect ReadyWorks becomes the orchestrator: the estate decides which VMs move in which wave, and these jobs execute that decision against the Move appliance.

NOTE: Six of the eight outbound templates ship with Enabled set to Yes, including Delete Migration Plan and Start Migration Plan. These jobs change the state of a live migration. Review the outbound job list and disable everything you do not intend to run before you attach this connection to production data.

Connector Properties

Authentication Methods

The connector ships one authentication method. It exchanges a Move appliance username and password for a JWT and uses that token for every subsequent call.

NOTE: The account used here needs enough privilege on the Move appliance to perform whatever the enabled outbound jobs do. If you enable only the inbound jobs, a read-capable account is sufficient. If you enable the plan lifecycle jobs, the account can create, start and delete migration plans.

Method 1: Nutanix Move: User/Pass to JWT Token (NUTANIX MOVE_bd1bfbc15b)

Username and Password to JWT Token

Posts the username and password as a JSON body (spec.username and spec.password) to the Authentication Token End Point, extracts the JWT from the Status.Token node named in Authentication Token JSON Node, and attaches it as a Bearer token on the data calls. Both the API Domain and the Authentication Token End Point ship with a placeholder hostname that must be replaced with your Move appliance address before the connection will work.

Connection Configuration Fields (7)

Authentication Configuration

Headers sent on the authentication call:

Headers sent on the data calls:

Authentication request body:

cURL options:

NOTE: The appliance FQDN appears in two separate fields, API Domain and Authentication Token End Point. Change both. Editing only the API Domain leaves the token request pointing at the placeholder host.

NOTE: This connection form does not expose the Single Authentication field, so the connector’s default of re-authenticating on every enumeration and pagination loop cannot be changed from the connection form.

Inbound Job Fields Enabled (45)

Inbound jobs expose the full REST job form, including the pagination group and all three enumeration levels, which the plan-scoped and provider-scoped jobs depend on.

Outbound Job Fields Enabled (13)

The outbound job form carries the fields that make the action templates work: the outbound field list that supplies identifiers into the endpoint path, the raw JSON outbound template that carries the request body, and the return data field list that captures the appliance’s response.

Inbound Job Templates (9)

Nine inbound templates ship. Five are working read jobs covering plans, providers, workloads, provider inventory and appliance configuration. The other four are identifier feeder jobs, shipped disabled, whose purpose is to supply the plan and provider identifiers that the plan-scoped and provider-scoped jobs need.

Job Template Configuration

Settings Common to All Nine Templates

Settings That Vary by Template

Settings That Vary by Template (continued)

Job Parameters and Enumeration

GET Migration Plans UUID

API data parameters:

GET Workloads

Enumeration 1 fields:

GET Providers Info

Enumeration 1 fields:

GET Providers Inventory

API data parameters:

Enumeration 1 fields:

NOTE: None of the inbound jobs set a Pagination Type. The appliance-scoped jobs return small collections, but GET Providers Inventory returns every VM in a source environment, which on a large vSphere estate is a substantial single response.

NOTE: The four feeder templates (GET Migration Plans UUID, GET Providers UUID - Enum 1, GET Providers UUID - Enum 2) ship disabled and stage nothing on their own. They exist to be pointed at by the enumeration configuration of the plan-scoped and provider-scoped jobs.

Outbound Job Templates (8)

Eight outbound templates ship, and unlike most connectors in this library they do not write records back into the source system. They drive the Move migration lifecycle: create a plan, check its readiness, prepare the guests, start it, act on individual VMs and delete the plan when it is done. Seven of the eight take a plan identifier from the outbound field list and substitute it into the endpoint path, and six carry a raw JSON body supplied from the ReadyWorks record.

Job Template Configuration

Settings Common to All Eight Templates

Settings That Vary by Template

Job Parameters and Enumeration

Create Migration Plan

Outbound fields list:

Return data fields:

Raw request body: %outbound_data%

Delete Migration Plan

Outbound fields list:

Return data fields:

Start Migration Plan

Outbound fields list:

Return data fields:

Raw request body: %outbound_data%

Get Migration Plan

Outbound fields list:

Return data fields:

Migration Plan Workloads

Outbound fields list:

Return data fields:

Raw request body: %outbound_data%

Migration Plan Readiness

Outbound fields list:

Return data fields:

Raw request body: %outbound_data%

Prepare VM’s

Outbound fields list:

Return data fields:

Raw request body: %outbound_data%

Perform Workload Action

Outbound fields list:

Return data fields:

Raw request body: %outbound_data%

NOTE: Six of these eight templates ship with Enabled set to Yes. Because they act on the appliance rather than write records to it, review the whole list and disable what you do not intend to run before the connection goes near production data.

NOTE: Seven templates place a plan_id in the endpoint path through the outbound field list. The plan identifier has to come from the ReadyWorks record driving the job, which normally means running GET Migration Plans UUID inbound first so the identifiers exist in the estate.

NOTE: Every template maps its response to a single return field labelled Response with no data object name set, so the appliance’s reply is not currently captured into a named field.