Nutanix Move v3 - 7

Move 3.
Move User Guide

May 20, 2021
Contents
Move Overview.................................................................................................. 6
Move Operations......................................................................................................................................... 7
Move Software Package............................................................................................................................. 8
Supported AOS, ESXi, and Hyper-V Version............................................................................................. 9
Firewall Port Requirements.........................................................................................................................9
Unsupported Features...............................................................................................................................12
Migration Limitations..................................................................................................................................12
Move Deployment............................................................................................14
Downloading Move and Invoking Move CLI............................................................................................. 14
Move Deployment on AHV....................................................................................................................... 15
Deploying Move on AHV (CLI).......................................................................................................15
Deploying Move on AHV (Prism Element UI)................................................................................ 17
Move Deployment on ESXi.......................................................................................................................18
Deploying Move OVA (ESXi Host Client)...................................................................................... 19
Deploying Move OVA (vCenter Client).......................................................................................... 19
Deploying Move OVA (VI Client)................................................................................................... 19
Logging in to Move UI.............................................................................................................................. 20
Initial Configurations.......................................................................................22
Changing Admin User Password.............................................................................................................. 22
Assigning a Static IP Address to Move.................................................................................................... 22
Assigning DHCP IP Address from Static IP Address............................................................................... 23
Move Dashboard............................................................................................. 24
Move Migration Workflow...............................................................................26
ESXi to AHV and ESXi to Nutanix Clusters on AWS VM Migration............ 27

Migration Considerations...........................................................................................................................27
Supported Guest Operating Systems............................................................................................ 27
Supported Operating Systems for UEFI Enabled VMs.................................................................. 28
Support for UEFI with Secure Boot Enabled VMs......................................................................... 28
Requirements..................................................................................................................................29
Recommendations for Migration.....................................................................................................31
Unsupported Features.................................................................................................................... 32
Limitations....................................................................................................................................... 32
Adding vCenter Server or Standalone ESXi Host Environment............................................................... 33
Adding a Nutanix AOS Cluster Environment............................................................................................ 34
Creating a Migration Plan......................................................................................................................... 35
Manual VM Preparation..................................................................................................................40
Creating a Test Capable Migration Plan........................................................................................41
Performing Data-Only Migration................................................................................................................47
Performing a Migration Cutover................................................................................................................ 48
ii
Performance Matrix for Large Data Migration.......................................................................................... 49
ESXi to ESXi VM Migration............................................................................ 51

Supported Guest Operating Systems (ESXi to ESXi)....................................................................51
Requirements (ESXi to ESXi)........................................................................................................ 57
Recommendations (ESXi to ESXi).................................................................................................60
Unsupported Features (ESXi to ESXi)...........................................................................................60
Limitations (ESXi to ESXi)............................................................................................................. 61
Adding vCenter Server or Standalone ESXi Host Environment............................................................... 61
Creating a Migration Plan (ESXi to ESXi)................................................................................................ 64
Manual VM Preparation (ESXi to ESXi).........................................................................................68
Performing a Migration Cutover (ESXi to ESXi)....................................................................................... 69
Performance Matrix for Large Data Migration (ESXi to ESXi)..................................................................70
Hyper-V to AHV and Hyper-V to Nutanix Clusters on AWS VM Migration.. 72

Requirements..................................................................................................................................75
Limitations....................................................................................................................................... 75
Adding Hyper-V Environment....................................................................................................................76
Deploying the Move Agent on Hyper-V Host........................................................................................... 78
Automatic VM Preparation for Hyper-V..........................................................................................84
Enabling WinRM............................................................................................................................. 86
Performing Data-Only Migration................................................................................................................87
Performing a Migration Cutover................................................................................................................ 88
Performance Matrix for Large Data Migration.......................................................................................... 89
AWS to AHV and AWS to Nutanix Clusters on AWS VM Migration............ 90

Requirements..................................................................................................................................91
Qualified Metrics............................................................................................................................. 92
Unsupported Features.................................................................................................................... 93
Limitations....................................................................................................................................... 94
Adding an AWS Environment................................................................................................................... 94
Automatic VM Preparation........................................................................................................... 101
Performing a Migration Cutover.............................................................................................................. 103
Performance Matrix for Large Data Migration........................................................................................ 104
AWS to ESXi VM Migration.......................................................................... 105

Migration Considerations.........................................................................................................................105
Supported Guest Operating Systems (AWS to ESXi)..................................................................105
Requirements (AWS to ESXi)...................................................................................................... 105
Qualified Metrics (AWS to ESXi)................................................................................................. 106
iii
Unsupported Features (AWS to ESXi).........................................................................................108
Limitations (AWS to ESXi)........................................................................................................... 108
Adding an AWS Environment................................................................................................................. 108
Adding a Nutanix AOS Cluster Environment.......................................................................................... 109
Creating a Migration Plan (AWS to ESXi).............................................................................................. 111
Automatic VM Preparation (AWS to ESXi).................................................................................. 114
Performing a Migration Cutover (AWS to ESXi).....................................................................................116
AHV to AWS VM Migration...........................................................................118

Migration Considerations.........................................................................................................................118
Supported Guest Operating Systems (AHV to AWS).................................................................. 118
Requirements (AHV to AWS).......................................................................................................118
Qualified Metrics (AHV to AWS).................................................................................................. 120
Unsupported Features (AHV to AWS)......................................................................................... 120
Limitations (AHV to AWS)............................................................................................................ 120
Adding a Nutanix AOS Cluster Environment.......................................................................................... 121
Adding an AWS Environment................................................................................................................. 122
Creating a Migration Plan (AHV to AWS)...............................................................................................123
Automatic VM Preparation (AHV to AWS)...................................................................................128
Performing a Migration Cutover (AHV to AWS)..................................................................................... 130
Environments and Migration Plan Management........................................ 131

Limits for Data Sync during Migration.................................................................................................... 132
Move Administration..................................................................................... 134

Move Upgrade Management...................................................................................................................134
Online Upgrade.............................................................................................................................134
Offline Upgrade.............................................................................................................................136
Undeploy Move........................................................................................................................................140
Undeploy Move (CLI)................................................................................................................... 140
Undeploy Move (Prism Element UI).............................................................................................141
Changing the Database Password......................................................................................................... 141
Configuring Time-Out for Source Inventory Refresh.............................................................................. 142
Move Troubleshooting.................................................................................. 143

Move Support Bundle Collection.............................................................................................................143
Downloading Support Bundle (UI)................................................................................................143
Downloading Support Bundle (CLI)..............................................................................................144
Accessing Move VM with SSH............................................................................................................... 144
Resetting Admin Password..................................................................................................................... 145
Resetting Web Login Password..............................................................................................................146
Changing Web Login Password..............................................................................................................147
Error Adding Source................................................................................................................................147
Error Adding Target.................................................................................................................................148
Missing Role Permission While Adding vCenter as a Provider.............................................................. 148
Manual Cleanup for VM Migrations........................................................................................................ 148
Changing Default TCP to KCP Protocol of Move...................................................................................150
Testing Network Performance of Move.................................................................................................. 151
Improving Migration Performance........................................................................................................... 152
Debugging Stats...................................................................................................................................... 153
Xtract Lite Deployment............................................................................................................................153
Troubleshooting UI Issues...................................................................................................................... 153
iv
Missing Static IP Address Post Migration...............................................................................................154
Bringing Disks Online Post Migration (Windows)................................................................................... 154
Copyright........................................................................................................155
v
MOVE OVERVIEW
Nutanix Move (Move) is a cross-hypervisor mobility solution to move VMs with minimal downtime. Move supports
migration from the following sources to targets, where first platform being the source and second platform being the
target.
• VMware ESXi to Nutanix clusters on AWS and AHV

• VMware ESXi on legacy infrastructure to VMware ESXi on Nutanix
• Microsoft Hyper-V to Nutanix clusters on AWS and AHV
• AWS EC2 to Nutanix clusters on AWS and AHV
• AWS EC2 to VMware ESXi on Nutanix
• Nutanix AHV to AWS EC2
Since the infrastructure underneath is different, a small downtime is incurred during cutover from any of the
preceding sources to targets.
Note: As a part of this workflow, a service disruption is expected during cutover.
Move Architecture
Move is a distributed application to support mobility from multiple sources such as ESXi, Hyper-V, AWS, and AHV.
Figure 1: Distributed Architecture of Move
Components of Move
The preceding diagram depicts the distributed architecture of Move which has the following components.
• Nutanix-Move: VM, which orchestrates the migration and can be accessed using the Move CLI or Move UI.
• Move Agent (termed as <source-vm-name>-NTNX-MOVE-AGENT) (only for AHV to AWS migrations):
When migrating from AHV to AWS, a Move agent runs on AWS as an EC2 instance of type t2.medium. This
Move | Move Overview | 6

Move agent instance is deployed in each of the source VMs. This Move agent interfaces with Nutanix-Move,
which uses Prism V3 APIs for snapshot management and facilitate the transfer of data from source to target.
Note: Move 3.7.1 and later versions support TLS 1.1 and TLS 1.2. If any operating system does not support TLS 1.1
and above, update the operating system with an appropriate patch before the migration or perform data only migrations
for such VMs.
Types of Migration
The Move components are used in the following ways during various types of migration:
• VMware ESXi to Nutanix AHV

When you are moving VMs from ESXi to AHV, Nutanix-Move directly communicates with vCenter (vCenter
is the management interface for the VMs running on the ESXi hypervisor) through the Management Server
and the Source Agent. VMware Guest Tools should be installed on the source VMs. The Source Agent collects
information from the VMware library about the VMs being migrated.
• VMware ESXi on legacy infrastructure to VMware ESXi on Nutanix
When you are moving VMs from VMware ESXi on legacy infrastructure to VMware ESXi on Nutanix, Nutanix-
Move directly communicates with Prism (management interface for the VMs running on AOS) through the
Management Server and the Source Agent.
• Microsoft Hyper-V to Nutanix AHV
When you are moving VMs from Hyper-V to AHV, a Move agent service is deployed on the Hyper-V host. This
Move agent communicates with the Source Agent and interfaces with the source VMs to facilitate the migration,
works with the Hyper-V host to take snapshots and transfers data from source to target. The Move agent is also
used for collecting source inventory.
• AWS EC2 to Nutanix AOS
When you are migrating EC2 instances from AWS to AOS (AHV and ESXi), the Amazon EBS direct APIs are
used to establish a connection between AWS and Nutanix-Move. For the actual transfer of data for the VM being
migrated (guest VM), Move takes snapshots of the EBS volumes of the VMs. The data path connection between
the Amazon EBS direct APIs and Nutanix-Move are used to transfer data from AWS to the target Nutanix Cluster.
Note: Nutanix converts the source VM disks to AHV format.
After the migration of the VM from the source to the target, Move deletes all EBS volume snapshots that were
taken by it.
Note: No other copies of the data are stored by Move.
• Nutanix AHV to AWS EC2

When you are moving VMs from AHV to AWS, Nutanix Guest Tools should be installed on the source VMs and
a Move agent instance (<source-vm-name>-NTNX-MOVE-AGENT) is deployed for each of the source VMs
on the target instance. Disk Writer is running as a server in this Move agent and initiates the connection with the
Disk Reader, and is used for writing data in the AWS EC2 instances. Prism V2 APIs are used for collecting the
inventory, and Prism V3 APIs are used for managing the snapshot lifecycle and querying the change block area.
Move Operations
You can perform the following operations with Move.
• Migrate powered on or powered off VMs.

• Pause and resume migration

• Schedule migration
• Schedule data-seeding for the virtual machines in advance and cut over to a new AHV cluster
• Manage VM migrations between multiple clusters from a single management interface
• Sort and group VMs for easy migration
• Monitor details of migration plan execution even at the individual VM level
• Cancel in-progress migration for individual VMs
• Migrate all AHV certified operating systems.
For more information, refer to Supported Guest VM Types for AHV topic in the latest version of the AHV
Administration Guide.
Move Software Package

Move software package contains Move ZIP file for AHV, Offline upgrade package, and Move OVA file for
ESXi.
You can download the Move software package from the Nutanix Support Portal.
Note: version-number in the utility name is the version number of Move.
Table 1: Move ZIP file for AHV: move-<version-number>.zip
The Move software package is delivered as a zip file, which contains the following contents.
Utility name Description
Deployer utility for the following operating systems:

• Cli-darwin-amd64-version-number
• Cli-linux-amd64-version-number • macOS
• Cli-windows-amd64-version-number.exe • Linux
• Windows
move-version-number.qcow2 Base disk image

move-version-number.qcow2.md5 Base disk image checksum
Table 2: Move Offline Upgrade Package: move-offline-upgrade-<version-number>.zip
Utility Name Description
Deployer utility for the following operating systems:

• Cli-darwin-amd64-version-number
• Cli-linux-amd64-version-number • macOS
• Cli-windows-amd64-version-number.exe • Linux
• Windows

move-offline-upgrade-version-number.tar.gz This offline upgrade package is for upgrading
Move VM to the latest available version without
connecting to the Internet by uploading the binary.
Table 3: Move OVA file for ESXi: mmove-<version-number>-esxi.ova
move-version-number-esxi.ova The Move OVA file for ESXi is used to deploy Move
on the ESXi target by uploading this file through
the ESXi host client, vCenter client, or Virtual
Infrastructure Client (VI Client).
Supported AOS, ESXi, and Hyper-V Version

For more information about the supported AOS, ESXi, and Hyper-V version with Move, refer to the Supported AOS,
ESXi, and Hyper-V Version section in the latest version of the Move Release Notes in the Nutanix Support Portal.
Firewall Port Requirements

The following tables provide the port numbers used by Move components. Use these firewall requirements
to configure rules in your external firewall to allow Move.
Figure 2: Firewall Port Diagram
Generic Ports
Table 4: Generic ports required to connect Nutanix-Move to DNS and NTP servers
Source Destination Port number Protocol
Nutanix-Move DNS Server 53 UDP

Source Destination Port number Protocol
NTP Server 123 UDP
Ports for All Source-Target Combinations
Table 5: User Workstation to Nutanix-Move
Source User Workstation

Destination Nutanix-Move
Port Protocol Description
22 TCP SSH for Linux guest VMs
80 TCP Move HTTP
443 TCP Move HTTPS
8082 TCP API docs
Ports for ESXi to AHV Migration
Note: Open the following ports from Nutanix-Move to all the CVMs in the AHV cluster.
Table 6: Nutanix-Move to Prism (AHV Cluster)
Source Nutanix-Move
Destination Prism (AHV Cluster)
80, 443, 9440 TCP Prism (AHV)
111, 2049 TCP, UDP Network File System (NFS)
Ports for ESXi to ESXi Migration
Table 7: Nutanix-Move to ESXi Source
Source Nutanix-Move
Destination ESXi Source
80, 443, 902 TCP Network File Copy (NFC) (ESXi)
Table 8: Nutanix-Move to vCenter
Source Nutanix-Move
Destination vCenter

80, 443 TCP Network File Copy (NFC) (ESXi)
Note: Open the following ports from Nutanix-Move to all the CVMs in the AOS cluster.
Table 9: Nutanix-Move to Prism (AOS Cluster)
Source Nutanix-Move
Destination Prism (AOS Cluster)
80, 443, 9440 TCP Prism (AOS)
Ports for Hyper-V to AHV Migration
Table 10: Nutanix-Move to Hyper-V Host
Source Nutanix-Move
Destination Hyper-V Host
5985, 5986 TCP WinRM for Windows guest VMs
8087 TCP Hyper-V Agent
Table 11: Nutanix-Move to Hyper-V Guest VM
Source Nutanix-Move
Destination Hyper-V Guest VM
22 TCP SSH for Linux guest VMs
5985, 5986 TCP WinRM for Windows guest VMs
Note: Open the following ports from Nutanix-Move to all the CVMs in the AHV cluster.
Table 12: Nutanix-Move to Prism (AHV Cluster)
Source Nutanix-Move
Destination Prism (AHV Cluster)
9440, 80, 443 TCP Prism (AHV)

Ports for AWS to AHV and ESXi (AOS) Migration
Table 13: Nutanix-Move to AWS
Source Nutanix Move

Destination AWS
443 TCP AWS
Ports for AHV to AWS Migration
Table 14: Nutanix-Move to NTNX-MOVE-AGENT
Source Nutanix-Move
Destination NTNX-MOVE-AGENT
3000, 3001, 3002 TCP Disk writer
Unsupported Features
This section lists the unsupported features of Move.
• IPV6
• VM names with non-English characters.
• VM names with single and double quotes.
• Windows VM installed with running antivirus software. Antivirus software prevents the installation of the VirtIO
drivers.
• Guest operating systems with deduplication enabled.
• In case of Hyper-V source VMs, logical 4K aligned VHDX images are not supported.
Migration Limitations
This section lists the limitations for migration from ESXi and Hyper-V.
The following migrations are not recommended, but can be performed with some limitations.
• Exchange should be migrated by installing newer versions of Exchange Server in parallel with existing production
environments, then move user mailboxes from the old system to the new one.
• Domain Controllers should be migrated by preparing a new domain controller, and then migrating the Flexible
Single Master Operations (FSMO) roles.

• Move migrates database VMs similar to any other VMs; however, the migration happens at the VM level, not the
application level. Move will not perform any application-level changes, disk layout updates, or best practices on
the migrated VM.
The above approach should be fine for smaller SQL DB servers and for servers without PCI Pass-through, pRDM
disks, or multi-writer disks (clustered NTFS). Also for larger SQL DB servers, Nutanix recommends you to apply
Nutanix best practices to create additional vDisks and rebalance data across those disks to take advantage of the
parallel nature of Nutanix distributed storage.
• Time taken for migration depends on the size of the VM, data churn rate within the VM during migration, and
network bandwidth/connectivity between source and on-prem datacenter.
• VMs managed by Citrix Hypervisor are known to have issues after migration.

MOVE DEPLOYMENT
Nutanix recommends to deploy Move in the AHV or ESXi cluster by using Prism Element UI or the Move
CLI. Once the deployment is successful, you can log on to the Move UI to perform the migration.
Note:
• As a best practice, it is recommended to deploy Move on the target cluster (AHV or ESXi on AOS).
• Deployment of Move in Prism Central is not supported. If a Prism Element is registered to Prism
Central, IP address of the Prism Element is used for deploying Move.
Downloading Move and Invoking Move CLI

To get started with Move, you can first download and invoke Move CLI on the target cluster, and then
deploy Move. If you are migrating to multiple AHV clusters, you can deploy Move on any of the target
clusters.
About this task
Note:
• Use Tab to automatically complete the parameters. Press Tab to see the command completion, and
press Tab again to enter the completion mode.
• Enter help along with any command, for information to display options for that command.
To download and invoke the Move CLI, do the following:
Procedure
1. Download the Move software package from Nutanix Support Portal.
2. Extract the zip file on your workstation.
3. Open the local CLI of your operating system.
Move | Move Deployment | 14

4. Browse to the extracted folder location and run the following command.
$ binary_name -c cluster_virtual_ip_address
Replace the binary_name with the name of the binary for your operating system.
For more information, refer to Move Software Package on page 8.
Note: The binaries for each operating system are similar to the following.
• macOS: ./cli-darwin-amd64-version-number
• Windows: cli-windows-amd64-version-number
• Linux: ./cli-linux-amd64-version-number
Replace cluster_virtual_ip_address with the FQDN or the IP address of the cluster.
Note: Use the -u parameter to log on. For more information, run the command ./binary_name --help.
Note: This address is either from Prism Element or the cluster VIP obtained from Prism. Prism Central is not
supported in Move.
An example command looks like the following with the subsequent parameters.
• macOS deployer utility

• AHV cluster
• IP address: 10.15.16.17
$ ./cli-darwin-amd64-3.3.1 -c 10.15.16.17
The Move CLI appears.
What to do next
You can deploy Move VM once the CLI is invoked. For more information, refer to Deploying Move on AHV
(CLI) on page 15
Move Deployment on AHV

Nutanix recommends to deploy the Move VM on the AHV target through CLI or Prism Element UI.
Note: As a best practice, it is recommended to deploy Move on the target cluster (AHV or ESXi on AOS).
Deploying Move on AHV (CLI)

Nutanix recommends to deploy the Move VM on the AHV cluster to which you want to migrate the VMs. By
default, DHCP is supported. Deploying the Move VM creates, uploads, and starts the Move VM. When you
invoke the deploy-vm command from the Move CLI with right set of options, the utility uploads the QCOW2
image in the target cluster, and deploys the Move application.
About this task
Note:
• Move deployment through CLI is not supported for ESXi on Nutanix.

• While deploying Move VM by using the CLI, use the Prism Element admin user credentials.

• Network should support DHCP. If the network only supports static IP address, Move tries to fetch the IP
address and if a IP address is not found, the deployment fails and you will be prompted for a clean up. If
you select Y, complete cleanup is performed. If you select N, Move VM deployed will not be deleted.
Following is an example of using a static IP address for deployment:
» deploy-vm vm-container DM_Nutest_Ctr vm-network static
Image is already present as a local file ./move-3.6.2.qcow2, nothing to download...
Image Download complete... [OK]
Creating image...
Uploading file ./move-3.6.2.qcow2
Image upload for Nutanix-Move completed [OK]
VM Deployment completed [OK]
VM Power on completed [OK]
Timed out querying for 'Nutanix-Move' to get IP address
Timed out querying for 'Nutanix-Move' to get IP address [ERROR]
Do you want to perform cleanup ? (y/N):
If DHCP is not supported, refer to Assigning a Static IP Address to Move on page 22 or Deploying
Move on AHV (Prism Element UI) on page 17.
• Move VM CLI deployment can show that the IP address query failed, but Move VM is up and running.
If Move VM is not allotted an IP address, contact Nutanix Support and refer to KB 6701.
• Use Tab to automatically complete parameters. Press Tab to see the command completion, and then
press Tab again to enter the completion mode.
To deploy Move VM on AHV, do the following:
Procedure
1. Open the Move CLI.

Refer to Downloading Move and Invoking Move CLI on page 14 for instructions about how to invoke the
Move CLI.
2. To deploy the Move VM, run the following command, and press Enter.
<cluster-name ip> >> deploy-vm vm-container storage_container vm-
network virtual_machine_network
<cluster-name ip> is the cluster name and IP address of the cluster. This prompt is displayed automatically.
Replace storage_container with the name of the storage container.
Note: To view a list of available storage containers, press Tab after deploy-vm vm-container.
Replace virtual_machine_network with the VM network name.

Following is an example of deploying Move VM with DHCP:
>> deploy-vm vm-container UserContainer-New vm-network Dynamic-Pool-10
Note: While deploying with DHCP if the IP address is not found, the deployment fails and you will be prompted
for a clean up. If you select Y, complete cleanup is performed. If you select N, the deployed Move VM will not be
deleted and you can later refresh to assign a IP address.
Successful completion creates, uploads, and starts the Move VM.
What to do next
You can access the Move UI. For more information, refer to Logging in to Move UI on page 20. If DHCP
is not enabled, refer to Assigning a Static IP Address to Move on page 22.

Deploying Move on AHV (Prism Element UI)
You can deploy the Move VM from the Prism Element UI. Deploying the Move VM creates, uploads, and
starts the Move VM.
Before you begin

Download the Move software package from the Nutanix Support Portal.
About this task
Note: To deploy the Move VM, you must use the qCOW2 image.
To deploy Move VM on AHV from Prism Element UI, do the following:
Procedure
1. Log on to the cluster on which you want to deploy Move by using your Prism Element admin credentials.
2. Click the gear icon pull-down list of the main menu.
3. Click Image Configuration.

The Image Configuration window is displayed.
4. To upload an image file to the cluster, click the + Upload Image button.
The Create Image window appears. Do the following in the indicated fields:
a. Name: Enter a name for the image.

b. Annotation (optional): Enter a description for the image.
c. Image Type (optional): Select the Disk image type from the pull-down list.
d. Container: Select the storage container to use from the pull-down list.
The list includes all containers created for this cluster. If there are no containers currently, a Create
Container link appears to create a container.
e. Image Source: Do one of the following:
» From URL: Click this option to import the qCOW2 image from the Internet. Enter the appropriate URL
address in the field.
» Upload a file: Click this option to upload a qCOW2 file from your workstation. Click the Choose File
button, and then select the Move qCOW2 image to upload from the file search window.
f. When all the fields are correct, click the Save button.
The Create Image window closes and the Image Configuration window reappears with the new image
appearing in the list.
Note: To verify, you can see the image upload progress in the Recent Tasks drop-down of the main menu.
5. Go to Home > VM.
6. Click + Create VM
The Create VM window appears.

7. Complete the indicated fields for creating a VM.
• Name: Enter a name for the VM.

• Description (optional): Enter a description for the VM.
• Timezone: Select the timezone of the VM as UTC.
• Use this VM as an agent VM: Select this option to make this VM as an agent VM.
You can use this option for the VMs that must be powered on before the rest of the VMs (for example,
to provide network functions before rest of VMs are powered on the host) and must be powered off and
migrated after rest of the VMs (for example, during maintenance mode operations).
• vCPU(s): Enter the number of virtual CPUs to allocate to this VM.
• Number of Cores per vCPU: Enter the number of cores assigned to each virtual CPU.
• Memory: Enter the amount of memory (in MiBs) to allocate to this VM.
Note: The new VM must meet the following minimum configuration.
• vCPU for each Core: 2

• Number of Cores: 2
• Memory: 4 GB
• NIC connected to the appropriate VM network - make sure that the Move VM can connect to
both source vCenter Server as well as target AHV cluster over this network. After selecting the
network on the Create NIC dialog box, you can provide a static IP address. You must provide
a static IP address if the network has IP address management enabled and no DHCP pool is
defined for it.
• You can ping the Move VM to determine if the VM is present on the network, or for any other
troubleshooting purposes.
8. Remove the current CDROM disk by clicking the X next to the CDROM.
9. Click + Add New Disk and select Operation > Clone from Image Service, and then in the Image drop-
down, select the uploaded image. Click Add.
10. Click the Table view and locate and select the new VM, and then click Power On.
11. Wait for the VM to detect an IP address.

The new Move VM is powered ON.
What to do next
You can access the Move UI. For more information, refer to Logging in to Move UI on page 20. If DHCP
is not enabled, refer to Assigning a Static IP Address to Move on page 22.
Move Deployment on ESXi

Nutanix recommends to deploy Move on the ESXi target by uploading the Move OVA file through the ESXi host
client, vCenter client, or Virtual Infrastructure Client (VI Client).
Note: As a best practice, it is recommended to deploy Move on the target cluster (AHV or ESXi on AOS).

Deploying Move OVA (ESXi Host Client)
You can deploy Move OVA through the ESXi Host Client for migrating VMs from ESXi to ESXi.
Before you begin

Download the Nutanix Move OVA file from Nutanix Support Portal.
About this task

To deploy Move OVA through the ESXi Host Client, do the following:
Procedure
1. Log on to ESXi Host Client.
2. Right-click Host in the VMware Host Client inventory, and then select Create/Register VM.
The New Virtual Machine wizard opens.
3. On the Select creation type page of the wizard, select Deploy a virtual machine from an OVF or OVA file,
and then click Next.
4. Click the blue pane, and select the Nutanix Move OVA file to deploy, and then click Open.
The file you have selected is displayed in the blue pane.
5. Enter the VM name, NIC, and other required details, and then click Next.
6. Click Finish.
Note: Depending on your network speed, the deployment can take up to 10 minutes or more.
The Move VM in now deployed.
Deploying Move OVA (vCenter Client)

You can deploy Move OVA through the vCenter client for migrating VMs from ESXi to ESXi.
Before you begin

About this task

To deploy Move OVA through the vCenter client, do the following:
Procedure
1. Log on to vCenter.
2. Click Deploy OVF Template.
3. Browse the Nutanix Move OVA file, and then click Next.
4. Enter the name of the VM, NIC, and other required details, and click Finish.
A success message appears when the Move VM is deployed.
Deploying Move OVA (VI Client)

You can deploy Move OVA through the VI client for migrating VMs from ESXi to ESXi.

Before you begin
About this task

To deploy Move OVA through the VI client, do the following:
Procedure
1. Log on to vCenter or ESXi host.
2. Click File > Deploy OVF Template.
3. Browse the Nutanix Move OVA file.
4. Enter the VM name, Data-store, Disk Format, and Network-Mapping details.
5. Click Finish.
The Move VM is now deployed.
Logging in to Move UI
Once the Move VM is deployed successfully and the Move VM is started, you can login to the Move user
interface (UI) using the Move VM IP address or the FQDN.
About this task

To log on to Move UI, do the following:
Procedure
1. Open a web browser, enter the FQDN or IP address of the VM.
2. (First-time log on only) If you are logging in for the first time, do the following:
a. Read the Nutanix End User License Agreement (EULA) agreement, click the I have read and agree to
terms and conditions option, and then click Continue.
b. In the Nutanix Customer Experience Program screen, click OK.
By participating in the Nutanix Customer Experience Program, Nutanix collects non-identifying information
for product improvement. Information such as type of source and target, number of migrated VMs, Move
version, operating system type of migrated VMs.
You can opt out of Nutanix Customer Experience Program from the Move dashboard after logging in. Click
the gear icon on the top-right corner, then click Experience Improvement. Uncheck the Participate check
box.
c. In the logon screen, set a password for the nutanix user in the Enter new password and Re-enter new
password fields and click Set Password.
3. In the logon screen, type the password of the nutanix user and press Enter.
Note: Default user of the Move UI is nutanix.

What to do next
Once logged on to the Move UI, you are now directed to the Move dashboard. For more information, refer
to Move Dashboard on page 24.

INITIAL CONFIGURATIONS
You can do the initial configurations, such as changing the default password, assigning the static IP addresses and
assigning the DHCP IP address from the static IP addresses.
Changing Admin User Password

Nutanix recommends that you secure the Move VM by changing the admin user password. After the initial
log on and set up, change the password for the admin user before you SSH into the Move VM.
About this task
Note: As a security measure, first-time SSH logon into Move VM with user as admin and default password
nutanix/4u requires a password change.
CAUTION: This password cannot be retrieved. Ensure that you keep this password in a secure location for your
retrieval.
To change the admin user password, do the following:
Procedure
1. SSH into the Move VM with the admin credentials. For more information, refer to Accessing Move VM with SSH
on page 144.
2. Change the admin password by entering passwd.

admin@<<move_vm_ipaddress>'s password:
3. Complete the fields by entering the new password.

admin@move on ~ $ passwd Changing password for user admin.
New password:
Retype new password:
The window displays a confirmation, passwd: all authentication tokens updated successfully.
Assigning a Static IP Address to Move

If DHCP is not enabled, you can assign static IP addresses for the Move VM.
About this task

To assign a static IP address, do the following:
Procedure
1. Log on to the Prism Element UI of the cluster with the admin user credentials where Move VM is deployed.
2. Go to Entity menu > Virtual Infrastructure > VMs .
3. Select the VM named Nutanix-Move.
4. Open a remote console on the Move VM and log on with the Move admin user credentials.
For more information about credential details, refer to Changing Admin User Password on page 22 topic.
Move | Initial Configurations | 22

5. Switch to the root user and enter the password of the Move VM.
admin@move on ~ $ rs
Note: For the first time, the script is run automatically when the Move CLI is launched.
6. Configure the static IP address.

root@move on ~ $ configure-static-ip
7. Enter the required information as shown in the following example.

Do you want to configure static IPv4 address?(y/N)
y
Enter Static IPv4 Address (e.g. 10.136.97.98)
10.136.7.1
Enter Netmask (e.g. 255.255.255.0)
255.255.255.0
Enter Gateway IP Address (e.g. 10.136.97.1)
10.136.72.1
Enter DNS Server 1 IP Address (e.g. 10.136.74.189)
10.136.72.189
Enter DNS Server 2 IP Address (e.g. 10.136.74.190)
10.136.72.190
Enter Domain (e.g. blr.ste.lab)
bltr.ste.lab
The static IP address is assigned successfully.
Assigning DHCP IP Address from Static IP Address

If your Move VM is assigned a static IP address, you can assign the IP address from static to DHCP.
About this task

To assign an IP address from static to DHCP, do the following:
Procedure
1. Deploy Move VM using the static network pool.
2. Launch the Move VM from the Prism Element UI, and then check the IP address.
The IP address is not assigned.
3. Delete the static NIC, and then add the DHCP NIC.
The IP address is still not assigned.
4. To configure DHCP, run the following command:

root@move on ~ $ configure-dhcp
The DHCP IP address is now assigned.
Move | Initial Configurations | 23

MOVE DASHBOARD
The Move dashboard displays dynamically updated information about the migration plans for the VMs
between source and target clusters.
Dashboard Options
The dashboard includes the following options:
• Environment. Displays all the added environments. Environments can be VMware ESXi, Nutanix AOS, Microsoft
Hyper-V and Amazon Web Services. Click + Add Environment to add locations to add locations for migrations
between them.
For more information, refer to Adding vCenter Server or Standalone ESXi Host Environment on page 33,
Adding a Nutanix AOS Cluster Environment on page 34, Adding an AWS Environment on page 94, and
Adding Hyper-V Environment on page 76.
• Create a Migration Plan. Set up the migration plan for one or more VMs you want to migrate to the target
environment. A migration plan includes scheduling options but does not start the cutover process.
For more information, refer to Creating a Migration Plan on page 35 or Creating a Migration Plan (ESXi to
ESXi) on page 64 or Creating a Migration Plan on page 79 or Creating a Migration Plan on page 97
or Creating a Migration Plan (AWS to ESXi) on page 111 or Creating a Migration Plan (AHV to AWS) on
page 123
• Manage an Environment or Migration Plan. Manage the existing environment or migration plans on the Move
dashboard. You can Refresh, Edit, or Remove an environment, and Start, Pause, Resume, Abort, Edit, or
Delete the migration plans.
For more information, refer to Environments and Migration Plan Management on page 131.
• Upgrade Software. Upgrade to a new version of Move to use the latest available features.
For more information, refer to Move Upgrade Management on page 134.
• Download Support Bundle. Generate and download a support bundle that you can send to Nutanix Support for
assistance.
For more information, refer to Move Support Bundle Collection on page 143.
• Help. Opens the latest version of the Move documentation.
• About Move. Check the latest version of the Move.
• Log Out. Sign out of Move VM.
Move | Move Dashboard | 24

Figure 3: Move Dashboard
Move | Move Dashboard | 25

MOVE MIGRATION WORKFLOW
You can prepare and migrate VMs by using Move once the Move VM is deployed successfully. The steps involved
during the entire migration process are as follows:
1. Log on to the Move UI.
2. Add environments for migration.
For more information, refer to Adding Environment section for specific environments.
3. Create a migration plan.
For more information, refer to Creating Migration Plan section for the specific source and target.
4. Prepare VMs automatically or manually.
For more information, refer to Preparing VMs Manually and Preparing VMs Automatically section for the specific
source and target.
5. Perform test migration or cutover for migration in target environment.
For more information, refer to Creating a Test Capable Migration Plan on page 41 or Performing Cutover
section for the specific source and target.
6. Manage migration plans.
For more information, refer to Environments and Migration Plan Management on page 131.
Note: Before you migrate VMs, Move does not detect whether the source VMs have security constructs or policies
(such as vTPM, BitLocker, or encrypted vDisks) enabled on those VMs. During the creation of a VM on the target
hypervisor (AHV), Move does not apply any security constructs or policies. Therefore, Move does not warrant the
integrity of such VMs if you decide to migrate them.
Move | Move Migration Workflow | 26

ESXI TO AHV AND ESXI TO NUTANIX
CLUSTERS ON AWS VM MIGRATION
You can prepare and migrate VMs running on ESXi hypervisor to AHV and ESXi to Nutanix Clusters on AWS by
using Move.
Move supports migration of vDisk partitions encrypted through cryptsetup in the Linux Unified Key Setup-on-disk-
format (LUKS) format.
Note:
• For migration from any source (ESXi, Hyper-V, and AWS) to AHV target and from any source (ESXi,
Hyper-V, and AWS) to Nutanix Clusters on AWS target, Move should be deployed on the same
destination target cluster where the VMs need to be migrated.
• For Nutanix Clusters on AWS, static IP retention is not enabled by default.
Migration Considerations
You must consider the supported guest operating systems, requirements, recommendations, unsupported features, and
limitations provided in this section before starting the migration process.
Supported Guest Operating Systems

Move provides full migration support for some common operating systems, and data-only support for other operating
systems. Unless otherwise specified, Nutanix has qualified the following 64-bit guest operating system versions.
Full migration support migrates the data, prepares the operating system with the required device drivers and scripts
for retaining the IP addresses, and recreates the VM on a target cluster. For full migration support in Windows, the
UAC must be disabled.
CAUTION: During full migration, UAC enabled on a Windows guest breaks the workflow of Move if a built-in local
administrator user is not used for migration.
If UAC is enabled or automatic VM preparation fails for certain VMs, you can choose to use manual
preparation to prepare such VMs.
For more information, refer to Manual VM Preparation on page 40.
Data-Only support migrates the data and recreates the VM on the target. Data-only support requires the user to install
the appropriate VirtIO drivers to each of these VMs. The following lists show the fully supported and data-only
supported guest operating systems.
For more information about the supported operating systems for the VMs created by using UEFI firmware, refer to
the Compatibility Matrix for UEFI Supported VMs section in the latest version of the AHV Administration Guide.
Note: Either Windows 7 or Windows Server 2008 R2 and earlier versions are not supported with UEFI on AHV.
Fully Supported
• Windows 7, 8, 8.1, 10
• Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019
Move | ESXi to AHV and ESXi to Nutanix Clusters on AWS VM Migration | 27

• RHEL 6.3 (32-bit and 64-bit supported) to 6.10, 7.0–8.2
Note: RHEL 6.3 is supported only with IDE as the disk controller.
• CentOS 6.3 (32-bit and 64-bit supported) to 6.9, 7.0–7.7, 8.0-8.2
Note: CentOS 6.3 is supported only with IDE as the disk controller.
• Ubuntu Server and Desktop 12.04.5, 14.04.x, 16.04.x, 16.10 (32-bit and 64-bit supported)
• Ubuntu Server 12.0.4, 18.04, 19.04, 20.04
• FreeBSD 9.3 and 11.0
• SUSE 11 SP3/SP4, SUSE 12, SUSE 12 SP1 / SP2 / SP3 / SP4
• Oracle Linux 6.4 and later, 7.x
Note: If you face kernel panic issue on Oracle Linux versions after migration to AHV, then refer and apply the KB
article 000004604 for these Oracle Linux VMs.
• Debian 9.4
Data-Only Support
• Windows with UAC enabled

• RHEL 5.11 with SATA disk controller (32-bit and 64-bit supported)
• CentOS 5.11 (32-bit and 64-bit supported)
• VMs requiring PCI or IDE bus
Supported Operating Systems for UEFI Enabled VMs

Move supports the following operating systems for UEFI enabled VMs.
Table 15: Supported Operating Systems
Operating systems
Windows 7, 10
Windows Server 2008, 2012, 2016, 2019
RHEL 7, 7.1, 7.5, 7.6, 8
CentOS 7, 7.1, 7.5, 7.6, 8
Support for UEFI with Secure Boot Enabled VMs

Move supports UEFI with secure boot enabled VMs.
Table 16: Supported Guest Operating Systems
Operating systems
Windows Server 2016, Windows Server 2019 (supported on AOS 5.19)

Operating systems
RHEL 7.7
CentOS 7.3
Requirements
Before attempting to migrate VMs running on ESXi by using Move, make sure to conform to the
requirements listed here.
General Requirements
Ensure to conform to the following requirements for ESXi to AHV and ESXi to Nutanix Cluster on AWS migration.
• Supported browser: Google Chrome

• Ensure you have PowerShell version 4.0 or later.
• VMware Tools must be installed and up-to-date on the guest VMs for migration.
• The VMs hardware version should be 7 or above to support the Changed Block Tracking (CBT) feature.
• Source VMs must support Changed Block Tracking (CBT). For more information, refer to VMware KB 1020128,
Changed Block Tracking (CBT) on Virtual Machines.
• Disks must be either sparse or flat format and must have a minimum version of 2.
• ESXi version must be minimum 5.1.
• Hosts must not be in maintenance mode.
• vCenter reachable from Move on port TCP 443.
Note: If vCenter is running on different port, make sure https://ip-address:port/sdk is accessible from the
Move VM.
• ESXi hosts should be reachable from Move on ports TCP 443 and TCP 902.
• Every VM must have a UUID.
• The configuration file (.vmx) of the VMs to be migrated should be present in the ESXi host.
• The VMs must be compatible with the multiple (more than one) snapshots taken by Move.
• Allow ports (TCP and UDP) 2049 and 111 between the Move network and the AHV CVM network.
• Accounts used for performing in-guest operations require Login as Batch Job rights in the local security policy
on Windows or within the group policy. Administrator users do not have sufficient rights.
This requirement is only applicable if the VM preparation mode is automatic.
• Ensure that you are an administrator for Windows source VMs or a root for Linux source VMs to run the
source VM preparation scripts.
• If local built-in administrator user performs guest preparation, admin approval mode should be disabled. By
default, admin approval mode is in disabled state. If the admin approval mode is in enabled state, refer to KB 7672
in the Nutanix Support Portal.
• Ensure that the Move user must belong in a group with Restore files and directories security policy.
• Ensure that the boot mode is configured as Legacy on the migrated target VMs if the source VMs are configured
with EFI in legacy compatibility mode.

Service Accounts
Move requires the following service accounts with admin privileges.
• vCenter Server
• Prism Element UI for the AHV cluster
Permissions Required on vCenter User for VM Migration

The following are the permissions that you must grant to vCenter user for successfully migrating your VMs by using
Move.
For more information about how to assign permissions, refer to Assigning Permission to vCenter User on
page 31.
Note: Update the privileges on the user level, not on the group level.
Global
• Disable methods
• Enable methods
• Licenses
Sessions
• Validate session
• View and stop sessions
Virtual machine
• Change Configuration
• Add existing disk

• Advanced configuration
• Change Settings
• Configure Raw device
• Modify device settings
• Remove disk
• Set annotation
• Toggle disk change tracking
• Guest operations
• Guest operation modifications

• Guest operation program execution
• Guest operation queries

• Interaction
• Connect devices
• Power off
• Power on
• Provisioning
• Allow read-only disk access

• Snapshot management
• Create snapshot Remove snapshot
Assigning Permission to vCenter User

You need to grant permissions to a vCenter user for successfully migrating your VMs by using Move.
About this task

To grant the permissions to a vCenter user, do the following:
Procedure
1. In the vSphere Web Client, select vCenter object (at the top of the hierarchy) in the inventory.
2. Click the Permissions tab.
3. Right-click the line item to select the user and the role pair.
4. Select Properties.
5. Select a role for the user from the drop-down menu.

The permission is granted to the vCenter user.
To know about the permissions required on vCenter user for VM migration, refer to Requirements (ESXi to ESXi)
on page 57 or Requirements on page 29.
For information about how to assign permissions, refer to the Global Permissions sections of the VMware vSphere
Product Documentation.
Recommendations for Migration

Nutanix recommends the following for optimal VM migration from ESXi.
Recommendations
• Clear all the VM alerts in vCenter, if any.

• Refresh the inventory.
• Convert the templates to VMs.
• Enable access to VMs from vCenter.
• Ensure that all VMs are connected through vCenter.
• Ensure that all VMs are valid in vCenter.
• Recover VMs fully, if any are orphaned.
• Ensure the disk compatibility with CBT.

• Disable fault tolerance for VMs, if any in a fault tolerance pair.
• Install the latest version of VMware Tools on the VMs to be migrated.
• Ensure that the CBT-enabled VMs have fewer than 30 snapshots in the inventory.
Note:
Move migrates maximum of 8 disks from single ESXi hosts in parallel. The other VMs for migration from
the same ESXi hosts are queued and only progress as and when the earlier disk data seeding completes. The
limit is 16 disks in parallel at the appliance level. Refer to KB-9460 for further information.
This topic lists the unsupported features for migration from ESXi to AHV and ESXi to Nutanix Cluster on
AWS.
• Guest operating systems not supported by AHV.

• PCIE pass-through
• Independent disks
• VMs with multi-writer disks attached
• VMs with 2 GB sparse disk attached
• VMs with SCSI controllers with a SCSI bus sharing attached
Note: Change SCSI bus controller to None.
• Migration of Windows VMs with dynamic disks

• Migration of VMs from ESXi standalone hosts with free license
Limitations
This section lists the limitations for migration from ESXi to AHV and ESXi to Nutanix Cluster on AWS, and
DNS configuration for the Move.
ESXi Migration Limitations

In addition to Migration Limitations on page 12, migration of 25 VMs in a plan is qualified and supported for ESXi
migration.
DNS Configuration for Migration from ESXi

DNS is configured during deployment and resolves the following.
• FQDN of the source ESXi host if the host is added using its FQDN in vCenter
• FQDN of the source vCenter if it is added using its FQDN
• FQDN of the target cluster

Warnings and Cautions
• Source VM disks attached to mix of PVSCSI and LSI adapters might get different device names (sda, sdb, and so
on)
Note: For Linux VMs, manually edit fstab. Then, arrange the correct order for the UUIDs.
Adding vCenter Server or Standalone ESXi Host Environment

While creating a migration plan for migration from ESXi to any target, ensure to add at least one vCenter
Server or standalone ESXi host environment for migration.
About this task
Note: This procedure is only applicable for migration from ESXi.
To add a vCenter Server or standalone ESXi host environment, do the following:
Procedure
2. Click + Add Environment under Environments..

The Add Source Environment window appears.
Figure 4: Add VMware ESXi Environment Dialog Box
3. Select VMware ESXi as the environment type.

4. Complete the indicated fields and click Add.
a. Environment Name: Enter a name for the ESXi environment.

b. vCenter Server or standalone ESX host: Enter the IP address or the FQDN of the vCenter Server, or the
IP address of the ESXi host.
If you do not have a standard port, use the custom port for vCenter in the vCenter IP address:custom port
number format. For example, if you are using IP address, use the format 10.136.72.150:8443 or if you are
using FQDN, use the format vcenter.nutanix.com:8443.
c. User Name: Enter the username for logging on to vCenter Server.
d. Password: Enter the password for logging on to vCenter Server.
The VMware ESXi environment is added to the Move UI and can be viewed in the Environments list in the left
pane of the Move dashboard.
What to do next
You can now add Nutanix AHV cluster environment. For more information, refer to Adding a Nutanix AOS
Cluster Environment on page 34
Adding a Nutanix AOS Cluster Environment

While creating a migration plan, if you need to add AHV and Nutanix Cluster on AWS as the source or
target, or ESXi on Nutanix as a target, you have to add at least one AOS cluster environment for migration.
About this task
Note: When you add a AOS cluster, Move VM IP address with the subnet 255.255.255.255 is added to the global NFS
allowlist.
CAUTION: Modifying the NFS allowlist of the destination container disables inheritance of the NFS
allowlist at the global level and lead to issues with Move operations.
To add a Nutanix AOS cluster environment, do the following:
Procedure

2. Click + Add Environment under Environments.
Figure 5: Add AOS Environment Dialog Box
The Add Environment window appears.
3. Select Nutanix AOS as the target environment type.
a. Environment Name: Enter a name for the Nutanix Cluster on AWS and AHV or VMware ESXi on Nutanix
environment.
b. Nutanix Environment: Enter the IP address or the FQDN for the target Prism Central or Prism Element.
c. User Name: Enter the username for logging on to the target Nutanix environment.
d. Password: Enter the password for logging on to the target Nutanix environment.
The AOS environment is added to the Move UI and can be viewed in the Environments list in the left pane of
the Move dashboard.
What to do next
Once you have added the environments, you can proceed to create the migration plan. For more
information, refer to Creating a Migration Plan on page 35 or Creating a Migration Plan on page 79 or
Creating a Migration Plan on page 97 or Creating a Migration Plan (AWS to ESXi) on page 111 or Creating
a Migration Plan (ESXi to ESXi) on page 64
Creating a Migration Plan

You can create a migration plan to seed the data, cutover, and monitor the VMs. You can create the
migration plan in Move UI without initiating the cutover process.
Before you begin

Ensure that you have added ESXi and AOS environments.

For more information, refer to Adding vCenter Server or Standalone ESXi Host Environment on page 33 and
Adding a Nutanix AOS Cluster Environment on page 34
About this task
Note:
• This procedure is only applicable for migration from ESXi to AHV and ESXi to Nutanix Cluster on
AWS.
• If you are logging in for the first time, log on to the Move UI with your default credentials.
• You must have admin user credentials to complete the migration process.
• If you restart the management server, scheduled VM migration does not begin automatically.
• If the source boot is set to UEFI, set up the boot device manually in the VM post migration for the
following operating systems.
• CentOS 7.4 2, 6.8 3, 8, 8.1, 8.2

• Ubuntu 12.04 4, 19.04
• OEL 7 5
• RHEL 6.8, 8.1
For more information about setting up the boot device, refer to Setting up Boot Device section in the
latest version of the AHV Administration Guide.
• While migrating Prism Central to AHV, the DHCP IP address of the Prism Central is not retained post
migration, and you have to reconfigure the IP address. IP address must be same before and after the
migration for proper connectivity between the Prism Central and the Prism Element.
• When Move encounters a large source VM disk of size greater than 2 TB that belongs to one ESXi host,
Move prioritize the migration of this disk and does not migrate any other disks from the same host in
parallel. Only after the large VM disk migration gets completed, Move migrates the other disks from the
same host. Meanwhile, Move migrates the VM disks belongs to other source ESXi hosts in parallel.
To create a migration plan, do the following:
Procedure
1. Log on to the Move VM.
2. On the Move dashboard, click Create a Migration Plan.
Note: If you have existing migration plans, click the + New Migration Plan link to create a plan.
The Enter Migration Plan Name window appears.

3. Enter the new migration plan name, and then click OK.
Note: You can edit the migration plan name by clicking the pencil icon next to the migration plan name.
The New Migration Plan window appears.
Figure 6: Create New Migration Plan
4. Complete the following fields, and then click Next.
a. Select a Source: Select any vCenter Server or standalone ESXi host as source for migration.
Once you select the source, an appropriate target appears.
Note: You might at times see a message relating to inventory collection as shown below. During this
time, the environments undergoing Refresh will not be available for selection. Such environments do not
automatically show up for selection once the inventory collection is over. In case you wish to select one of the

environments undergoing Refresh (not available for selection), you will need to select Cancel and wait for
inventory collection to get over and then create the migration plan again.
Figure 7: Inventory Collection Message

b. Select a Target: Select any Nutanix Cluster on AWS and AHV target for the migrating VMs.
c. Target Containers: Select the container on which you will migrate the VMs.
5. In the Select VMs screen, select one or more VMs from the list. To add all the VMs, click +Add All, and then
click Next.
Note: You cannot add more than 25 VMs in a single migration plan.
You can filter the VMs by name in the Filter bar. You can also sort the VM types by selecting the appropriate
column. The VMs for which migration has failed are not displayed. To show the entire list of VMs, select All
VMs from the drop-down list. To show the configuration of VMs, select Configuration from the drop-down
list. A question mark icon appears beside the unavailable VM, which displays more information about that VM
and indicate why the VM cannot be migrated.
Note:
• If the source VM has RDM disks in physical compatibility mode, then those disks are converted to
virtual compatibility mode during source VM preparation. By default, power cycle is enabled for
the VMs with physical RDM disks. Move performs the following:
1. Shut down the source VM.
2. Convert physical RDM disks to virtual compatibility mode.
3. Start the VM.
If power cycle is not enabled, then Move converts the physical RDM disks to virtual with VM in
powered on state.
• Migrate VMs retain their power state on the destination cluster.
The selected VMs are displayed in the sidebar.

6. In the Network Configuration screen, select the target network from the drop-down, and then click Next.
For performing test migration, refer to Creating a Test Capable Migration Plan on page 41 section.
7. In the VM Preparation screen, select one of the following VM preparation modes.
» Automatic. Move automatically runs scripts on the source VMs to prepare them for migration. If you select
this option, you must provide the credentials of the source VMs under Windows VMs or Linux VMs,
depending on the type of the source VM.
Alternatively for Linux VMs only, select the Use Private (.PEM) file to authenticate option and upload
the private key for authentication.
Note: If you want to retain the static IP addresses, provide a common set of credentials for your selected
Windows or Linux VMs.
» Manual. Move displays the VM preparation scripts for Windows and Linux VMs. Copy the scripts and
manually run them on the source VMs.
For more information, refer to Manual VM Preparation on page 40.
» Mixed. Move allows you to select the VM preparation mode for each VM. This setting allows you to
manually prepare one set of VMs and automatically prepare another set of VMs in the same migration plan.
If you want to have such a hybrid combination of Automatic and Manual VM preparation modes, proceed
to the next step.
Note: The preparation mode automatically switches to Mixed if you change the mode of preparation for a set
of VMs under Change Settings and have a mix of Automatic and Manual VM preparation modes. You
cannot manually select the Mixed option from the Preparation Mode drop-down list.
To perform data-only migration, refer to Performing Data-Only Migration on page 47.
8. In the Override individual VM Preparation section, click Change Settings to override the same settings
for the individual VMs. You can also update the username and password of the VMs, remove unwanted VMs, or
update the VM preparation mode.
a. For the VMs whose mode of preparation you want to change, under Mode of Preparation, click Edit.
b. In the Edit VM Preparation Preferences screen, select the mode of preparation (Automatic or
Manual) and click Done.
Note: If you select Manual, you must copy the displayed scripts and run them on the source VMs.

9. (Optional) In the VM Preparation screen, do one or more of the settings, and then click Next.
a. Retain MAC Addresses from the Source VMs: Select this check box to retain the MAC addresses
from the source VMs.
b. Bypass Guest Operations on Source VMs: Select this check box to bypass the guest operating system
changes.
You can select this option to override your migration to data-only migration.
c. Timezone: Set the timezone as the hardware clock of the VMs in target.
If set to default, Move configures UTC timezones for Linux VMs and cluster timezones for Windows VMs.
d. Settings for individual VMs: Click to change the settings such as retain MAC addresses, bypass guest
operations, and timezone for individual VMs. You can also search the VM by typing the name of the VM
and change the settings.
e. Schedule Data Seeding: Check this check box to select the date and time for migration.
Note: For migration of VMs with multiple NICs, static IP address configurations are applied correctly if the
MAC address retention is applied from source VMs, otherwise best effort IP address configuration is done by
mapping one NIC at a time.
This action does not affect the VM data migration but requires you to manually prepare the guest operating
system with the necessary AHV drivers prior to cutover. In addition, if you bypass the guest operations, you
have to take care of the static IP address retention separately.
10. In the Summary screen, choose one of the following, and then proceed review the VM migration summary.
» Back: To edit the information, click this option.

» Save: To save the migration plan, click this option.
For more information about how to start the migration later, and check the migrated VM status and details,
refer to Environments and Migration Plan Management on page 131.
» Save and Start: Click this option to save the migration plan and begin the migration immediately.
The seeding process for migration begins. You can monitor this information by selecting Status for the
migration plan.
Note: The seeding process can take several minutes depending on the number of VMs.
What to do next
If you have started the migration, the next step is to perform the cutover. For more information, refer to
Performing a Migration Cutover on page 48
Manual VM Preparation
You can also prepare the VMs manually by running the scripts provided in the Move UI.
About this task
Note: For running the script, use the Windows built-in administrator credentials for the Windows VMs and use root
user for the Linux VMs.
To manually download and run the migration preparation software, do the following:

Procedure
1. In the VM Preparation screen, select Manual.
Note: If you have not run the preparation script in the source VMs, Move performs data-only migration.
For more information, refer to Performing Data-Only Migration on page 47.
2. Run the scripts provided in VM Preparation in the respective source VMs, and then click Next.
These scripts prepare the source VMs by performing the following.
• Installs NTNX VirtIO driver

• Runs the IP address retention script
You can also do the following settings.
a. Change Settings: Click to override the same settings for the individual VMs. You can update the username
and password of the VMs, remove unwanted VMs, or update the VM preparation mode.
b. Retain MAC Addresses from the Source VMs. Check this check box to retain the MAC addresses from
the source VMs.
d. Manage Settings for individual VMs: Click to change the settings such as retain MAC addresses, bypass
guest operations, and timezone for individual VMs. You can also search the VM by typing the name of the
VM and change the settings.
e. Schedule Data Seeding: Check the box to select the date and time for migration.
The VM preparation takes place.
3. In the Summary screen, select one of the following, and then proceed review the VM migration summary.

For more information about how to start the migration later, refer to Environments and Migration Plan
Management on page 131.
.
» Save and Start: Click this option to save the migration plan and begin the migration immediately
The seeding process for migration begins. You can monitor this information by selecting Status for the migration
plan.
What to do next
Creating a Test Capable Migration Plan

Creating a test capable migration plan is an optional feature to test the VMs on the target environment prior
to the final cutover. During the final cutover, the source VMs are powered off which disrupts the underlying
data replication. You can test multiple VMs with this feature without disrupting the source VMs. After the

test, you can continue with the final cutover in your production environment. This feature supports all
provider combinations except Nutanix Cluster on AWS and AHV to AWS.
Before you begin

Ensure that you have added the source and target environments before creating the migration plan.
Note:
• ESXi to AHV and ESXi to Nutanix Cluster on AWS VM migration is used as a sample test migration
plan.
• Test migration is supported for all provider combinations except Nutanix Cluster on AWS and AHV to
AWS.
• Refer to specific migration plans in this guide for information on how to add the required environments.
Procedure
1. Log on to the Move VM.
Figure 8: Migration Plan Window
a. Select a Source: Select any vCenter Server or standalone ESXi host as source for migration.
b. Select a Target: Select any Nutanix Cluster on AWS and AHV target for the migrating VMs.

click Next.
The Network Configuration window appears.
Figure 9: Network Configuration Window
6. On the Network Configuration screen, select the target Nutanix Cluster on AWS and AHV from the Target
Network drop-down.
Test Network (Optional) is enabled.
7. Select the test network from the Test Network (Optional) drop-down, and then click Next.
Note:
• Test Network (Optional) is activated only after the target network is selected.
• To avoid conflicts, the Test Network (Optional) drop-down lists all other networks except the
one selected by the target network.
• Test Network (Optional) is an optional feature and you can skip it to go directly to the
production target.
8. In the VM Preparation screen, select Automatic from the Preparation Mode drop-down.
In this example, Automatic preparation mode is selected. Refer to specific migration plans for Manual and
Mixed preparation mode. You can choose based on your requirement.

9. In Credentials for Source VMs , provide the credentials for your Windows or Linux source VMs, and then
click Next.
The Migration Plan Summary page appears.
Figure 10: Migration Summary Page
10. On the Summary screen, review the migration summary details and click Save and Start.
The Move Dashboard appears with the existing migration plans and the seeding process begins.
Figure 11: Move Dashboard with Existing Migration Plans

11. Click In Progress to monitor the progress of the migration.
The Migration Plan Details window appears.
Figure 12: Migration Plan Details Window
Note:
• All tabs are disabled until you chose a VM and enabled at different stages as needed.
• During the migration, if you select the VM, only the Abort function is enabled for canceling the
migration plan.
• If there is any failure, the Retry and the Discard functions are enabled.
12. After the migration status changes to Ready to Cutover, the following actions are enabled:
» Test Actions: Click to continue with testing the VMs on the target environment.
» Cutover : Click to continue with normal migration process in the production environment.

13. Select Create Test VM from the Test Actions drop-down. The source VMs remain powered on and a test
VM is created in the target environment.
This process takes some time.
Click Continue on the dialog box.
Figure 14: Confirmation Dialog Box
14. Click View Test VM option created under the Migration Status tab under Ready to Cutover.
The following options are enabled after you click Test Actions:
» Recreate Test VM: Click to recreate a test VM.

» Remove Test VM: Click to remove the deployed test VMs from the target and changes the VM status back
to Ready to Cutover.
15. Click View Test VM.

A new window for the target network opens up.
16. Enter the credentials of the source VM to log on.

17. Look for the test VM and perform test operations.
Note: Test VMs are suffixed with -MoveTest in the target network.
18. Once you test the VMs in the target environment, come back to the Move Dashboard and select Cutover to
continue with normal migration to the production environment.
You can click Remove Test VM to clean up the target environment and click Recreate Test VM to perform
the test again.
What to do next
You can perform test migrations for all types of migration supported by Move except Nutanix Cluster on
AWS and AHV to AWS migration. For more information about creating migration plan and performing
test migration for supported environments, refer to Creating a Migration Plan on page 35 or Creating
a Migration Plan (ESXi to ESXi) on page 64 or Creating a Migration Plan on page 79 or Creating a
Migration Plan on page 97 or Creating a Migration Plan (AWS to ESXi) on page 111.
Performing Data-Only Migration

When you select Automatic preparation mode while creating a migration plan, you can perform data-only
migration either by bypassing the guest operations or without providing the credentials while preparing a
migration plan. When you select Manual preparation mode while creating a migration plan, do not run the
preparation script in the source VMs to perform data-only migration.
About this task
Note: Data-only migration is only supported from ESXi to AHV and ESXi to Nutanix Cluster on AWS, and Hyper-V
to AHV and Hyper-V to Nutanix Cluster on AWS migrations.
To perform data-only migration, do the following:

Procedure
1. In the VM Preparation screen, if you select Automatic, then proceed without providing the credentials for the
source VMs or select the Bypass Guest Operations on Source VMs check box or if you select Manual, do
not run the preparation script in the source VMs.
The following message appears when the Automatic preparation mode is selected,
Figure 16: OS Credentials Dialog Box
2. Click Continue.
Move migrates the VMs data and creates a VM in the target, and bypasses the operating system operations.
Performing a Migration Cutover

When the migration plan is started and the seeding process is complete, you can cut over the selected
VMs to the Nutanix Cluster on AWS and AHV cluster. You can monitor the VM migration progress by
clicking the Status link.
About this task
Note:
• You can perform this operation only when the VM status is Ready to Cutover.
• Recommended that cutover should be performed within one week of initial data seeding.
• If the initial data seeding finishes in less than 10 minutes, the Move VM continues to wait for 10
minutes to take the incremental snapshot; however, you can trigger the cutover immediately.
• The cutover process increments in absolute numbers.
To perform the migration cutover, do the following:

Procedure
1. In the Move UI, click the Ready to Cutover status to display the list of available VMs.
2. To perform a cutover, select the VMs or group of VMs.
3. Click Cutover.
The cutover process performs the following VM actions.
• Shuts down the VM

• Takes the final snapshots for the VM and copying the final changes to Nutanix Cluster on AWS and AHV
• Adds a note in the VM in the vCenter.
• Disconnects the source VM network interfaces
• Creates a VM in the target Nutanix Cluster on AWS and AHV cluster
• Attaches the replicated disks to the VM
• Powers on or off the VM (depends on the initial power state)
• Runs the scripts to set the static IP address
The cutover process begins immediately and takes a few minutes. Once cutover is complete, the VM is ready for
use in the new Nutanix Cluster on AWS and AHV cluster.
What to do next
You can manage the migration plan once the migration plan is ready. For more information, refer to
Environments and Migration Plan Management on page 131
Performance Matrix for Large Data Migration

Move performs end-to-end migration of large VMs. The scenarios are tested based on the following
parameters. The following tables show the performance numbers from the Move lab.
Table 17: Performance Numbers of Large Data Migration (ESXi to AHV )
Total Number Size for Number Source Data Network Migration time Platform
migration of VMs each of I/O churn bandwidthtaken
size vDisks vDisks
Data Cutover
seeding
2 TB 1 2 TB 1 No No 10 G 190 Less NX-3040-
minutes than 5 G4 (All
minutes Flash)
2 TB 1 512 GB 4 No No 10 G 90 Less NX-3040-
minutes Flash)
minutes Flash)

Total Number Size for Number Source Data Network Migration time Platform
migration of VMs each of I/O churn bandwidthtaken
size vDisks vDisks
minutes Flash)
3.6 TB 1 Ranges 27 No No 10 G 12 hours 5 NX-3060-
from 1.5 minutes G6
TB to 2
GB
1 TB 1 1 TB 1 Yes 10 GB 1G 418 28 NX-1065S
minutes minutes

ESXI TO ESXI VM MIGRATION
You can prepare and migrate ESXi VMs running on non-Nutanix appliances to ESXi on Nutanix appliances by using
Move.
Move supports migration of vDisk partitions encrypted through cryptsetup in the Linux Unified Key Setup-on-disk-
format (LUKS) format.
Note: ESXi as a source refers to ESXi running on non-Nutanix appliances.
Supported Guest Operating Systems (ESXi to ESXi)

Move provides full migration support for the following guest operating systems for ESXi to ESXi migration.
Note: Guest operating systems outside this list are not supported.
Table 18: Fully Supported Guest Operating Systems
Name Description
asianux3_64Guest Asianux Server 3 (64 bit)

Since vSphere API 4.0
asianux3Guest Asianux Server 3


asianux4Guest Asianux Server 4


centos64Guest CentOS 4/5 (64-bit)
centosGuest CentOS 4/5

darwin10_64Guest Mac OS 10.6 (64 bit)

darwin10Guest Mac OS 10.6

Move | ESXi to ESXi VM Migration | 51

Name Description
darwin11Guest Mac OS 10.7



darwin64Guest Mac OS 10.5 (64 bit)

darwinGuest Mac OS 10.5

debian4_64Guest Debian GNU/Linux 4 (64 bit)
debian4Guest Debian GNU/Linux 4









dosGuest MS-DOS.

Name Description
eComStation2Guest eComStation 2.0
eComStationGuest eComStation 1.x

fedora64Guest Fedora Linux (64 bit)

fedoraGuest Fedora Linux

freebsd64Guest FreeBSD x64

freebsdGuest FreeBSD
genericLinuxGuest Other Linux
mandrakeGuest Mandrake Linux

mandriva64Guest Mandriva Linux (64 bit)

mandrivaGuest Mandriva Linux

netware4Guest Novell NetWare 4

netware5Guest Novell NetWare 5.1
netware6Guest Novell NetWare 6.x
nld9Guest Novell Linux Desktop 9
oesGuest Open Enterprise Server
openServer5Guest SCO OpenServer 5
openServer6Guest SCO OpenServer 6

opensuse64Guest OpenSUSE Linux (64 bit)

opensuseGuest OpenSUSE Linux

oracleLinux64Guest Oracle Linux 4/5 (64-bit)


Name Description
oracleLinuxGuest Oracle Linux 4/5
os2Guest OS/2
other24xLinux64Guest Linux 2.4x Kernel (64 bit) (experimental)
other24xLinuxGuest Linux 2.4x Kernel
other26xLinux64Guest Linux 2.6x Kernel (64 bit) (experimental)
other26xLinuxGuest Linux 2.6x Kernel
other3xLinux64Guest Linux 3.x Kernel (64 bit)
other3xLinuxGuest Linux 3.x Kernel

otherGuest Other operating system

otherGuest64 Other operating system (64 bit) (experimental)
otherLinux64Guest Linux (64 bit) (experimental)
otherLinuxGuest Linux 2.2x Kernel
redhatGuest Red Hat Linux 2.1
rhel2Guest Red Hat Enterprise Linux 2
rhel3_64Guest Red Hat Enterprise Linux 3 (64 bit)
rhel5_64Guest Red Hat Enterprise Linux 5 (64 bit) (experimental)
Since VI API 2.5

Since VI API 2.5




sjdsGuest Sun Java Desktop System

Name Description
sles10_64Guest SUSE Linux Enterprise Server 10 (64 bit)
(experimental)
Since VI API 2.5
sles10Guest SUSE Linux Enterprise Server 10

Since VI API 2.5

sles11Guest SUSE Linux Enterprise Server 11


sles12Guest SUSE linux Enterprise Server 12

sles64Guest SUSE Linux Enterprise Server 9 (64 bit)

slesGuest SUSE Linux Enterprise Server 9
solaris10_64Guest Solaris 10 (64 bit) (experimental)
solaris10Guest Solaris 10 (32 bit) (experimental)
solaris11_64Guest Solaris 11 (64 bit)
solaris6Guest Solaris 6
suse64Guest SUSE Linux (64 bit)
suseGuest SUSE Linux
turboLinux64Guest Turbolinux (64 bit)
turboLinuxGuest Turbolinux
ubuntu64Guest Ubuntu Linux (64 bit)
ubuntuGuest Ubuntu Linux
unixWare7Guest SCO UnixWare 7
vmkernel5Guest VMware ESX 5


Name Description
vmkernel6Guest VMware ESX 6
vmkernelGuest VMware ESX 4

win2000AdvServGuest Windows 2000 Advanced Server

win2000ProGuest Windows 2000 Professional
win2000ServGuest Windows 2000 Server
win31Guest Windows 3.1
win95Guest Windows 95
win98Guest Windows 98
windows7_64Guest Windows 7 (64 bit)
windows7Guest Windows 7
windows7Server64Guest Windows Server 2008 R2 (64 bit)

windows8_64Guest Windows 8 (64 bit)

windows8Server64Guest Windows 8 Server (64 bit)

windows9_64Guest Windows 10 (64-bit)

windows9Server64Guest Windows Server 2016 (64-bit)
windowsHyperVGuest Windows Hyper-V
winLonghorn64Guest Windows Longhorn (64 bit) (experimental)

Since VI API 2.5
winLonghornGuest Windows Longhorn (experimental)

Since VI API 2.5
winMeGuest Windows Millenium Edition

winNetBusinessGuest Windows Small Business Server 2003

Name Description
winNetDatacenter64Guest Windows Server 2003, Datacenter Edition (64 bit)
(experimental)
Since VI API 2.5
winNetDatacenterGuest Windows Server 2003, Datacenter Edition

Since VI API 2.5
winNetEnterprise64Guest Windows Server 2003, Enterprise Edition (64 bit)

winNetEnterpriseGuest Windows Server 2003, Enterprise Edition
winNetStandard64Guest Windows Server 2003, Standard Edition (64 bit)
winNetStandardGuest Windows Server 2003, Standard Edition
winNetWebGuest Windows Server 2003, Web Edition
winNTGuest Windows NT 4
winVista64Guest Windows Vista (64 bit)
winVistaGuest Windows Vista
winXPHomeGuest Windows XP Home Edition
winXPPro64Guest Windows XP Professional Edition (64 bit)
winXPProGuest Windows XP Professional

Operating systems
RHEL 7.7
CentOS 7.3
Requirements (ESXi to ESXi)

Before attempting to migrate VMs running on ESXi using Move, make sure to conform to the requirements
listed here.
General Requirements for ESXi to ESXi Migration

Ensure to conform to the following requirements for ESXi to ESXi migration.

• VMware Tools must be installed and up-to-date on the guest VMs for migration.
• The VMs hardware version should be 7 or above to support the Changed Block Tracking (CBT) feature.

• Source VMs must support Changed Block Tracking (CBT).
For more information, refer to VMware KB 1020128, Changed Block Tracking (CBT) on virtual machines.
• Disks must be either sparse or flat format and must have a minimum version of 2.
• ESXi version must be minimum 5.1.
• Hosts must not be in maintenance mode.
• vCenter reachable from Move on port TCP 443.
Note: If vCenter is running on different port, make sure https://ip-address:port/sdk is accessible from the
Move VM.
• ESXi hosts should be reachable from Move on ports TCP 443 and TCP 902.
• Every VM must have a UUID.
• The configuration file (.vmx) of the VMs to be migrated should be present in the ESXi host.
• The VMs must be compatible with the multiple (more than one) snapshots taken by Move.
• Allow ports (TCP and UDP) 2049 and 111 between the Move network and the AHV CVM network.
• Accounts used for performing in-guest operations require Login as Batch Job rights in the local security policy
on Windows or within the group policy. Administrator users do not have sufficient rights.
This requirement is only applicable if the VM preparation mode is automatic.
• Ensure that you are an administrator for Windows source VMs or a root for Linux source VMs to run the
• Ensure that the Move user must belong in a group with Restore files and directories security policy.
Service accounts
Move requires the following service accounts with admin privileges.
• vCenter Server
• Prism Element UI for the ESXi on Nutanix cluster
Permissions Required on vCenter User for VM Migration

The following are the permissions that you must grant to vCenter user for successfully migrating your VMs by using
Move.
For more information about how to assign permissions, refer to Assigning Permission to vCenter User on page 31.
Note: Update the privileges on the user level, not on the group level.
Global
• Disable methods
• Enable methods
• Licenses
Sessions

• Validate session
• View and stop sessions
Virtual machine
• Change Configuration
• Add existing disk

• Advanced configuration
• Change Settings
• Configure Raw device
• Modify device settings
• Remove disk
• Set annotation
• Toggle disk change tracking
• Guest operations
• Guest operation modifications

• Guest operation program execution
• Guest operation queries
• Interaction
• Connect devices
• Power off
• Power on
• Provisioning
• Allow read-only disk access

• Snapshot management
• Create snapshot Remove snapshot
Assigning Permission to vCenter User

You need to grant permissions to a vCenter user for successfully migrating your VMs by using Move.
About this task

To grant the permissions to a vCenter user, do the following:
Procedure
1. In the vSphere Web Client, select vCenter object (at the top of the hierarchy) in the inventory.
2. Click the Permissions tab.
3. Right-click the line item to select the user and the role pair.

4. Select Properties.
5. Select a role for the user from the drop-down menu.

The permission is granted to the vCenter user.
To know about the permissions required on vCenter user for VM migration, refer to Requirements (ESXi to ESXi)
on page 57 or Requirements on page 29.
For information about how to assign permissions, refer to the Global Permissions sections of the VMware vSphere
Product Documentation.
Recommendations (ESXi to ESXi)

Nutanix recommends the following for optimal VM migration from ESXi.
Recommendations
• Clear all the VM alerts in vCenter, if any.

• Refresh the inventory.
• Convert the templates to VMs.
• Enable access to VMs from vCenter.
• Ensure that all VMs are connected through vCenter.
• Ensure that all VMs are valid in vCenter.
• Recover VMs fully, if any are orphaned.
• Ensure the disk compatibility with Changed Block Tracking(CBT).
• Disable fault tolerance for VMs, if any in a fault tolerance pair.
• Install the latest version of VMware Tools on the VMs to be migrated.
• Ensure that the CBT-enabled VMs have fewer than 30 snapshots in the inventory.
Note: Move migrates maximum of 8 disks from single ESXi hosts in parallel. The other VMs for migration from the
same ESXi hosts are queued and only progress as and when the earlier disk data seeding completes. The limit is 16
disks in parallel at the appliance level. Refer to KB-9460 for further information.
Unsupported Features (ESXi to ESXi)

This section lists the unsupported features for migration from ESXi to ESXi.
• Guest operating systems not supported by AHV.

• PCIE pass-through
• Independent disks
• VMs with multi-writer disks attached
• VMs with 2 GB sparse disk attached
• VMs with SCSI controllers with a SCSI bus sharing attached
Note: Change SCSI bus controller to None.

• Migration of Windows VMs with dynamic disks
• Migration of VMs from ESXi standalone hosts with free license
Limitations (ESXi to ESXi)

This section lists the limitations for migration from ESXi to ESXi.
ESXi to ESXi Migration Limitations

In addition to Migration Limitations on page 12, the following are the limitations while performing migration from
ESXi to ESXi.
• MAC addresses are not preserved. As a result, static IP address retention does not work for multiple NICs.
• For standalone ESXi migrations, you should not use vMotion or Storage vMotion on the VMs under migration.
• Containers that are mounted on all the ESXi hosts are available for selection as the container for the ESXi target.
• VMs with E1000e NIC cannot be migrated from ESXi to ESXi on AOS 5.4 and earlier versions.
• The target ESXi must be registered with vCenter while adding it as a target and must be registered for the entire
duration of its existence as an entity with Move.
• The virtual hardware version of VMs defaults to the ESXi target version and VMs fails to start after migration.
Workaround: Reinstall the VMware Tools in the target.
• VMs with UEFI boot configuration do not boot after migration.
Workaround: Manually update the VM configuration. Refer to the VMware KB article Enable or Disable UEFI
Secure Boot for a Virtual Machine.
Adding vCenter Server or Standalone ESXi Host Environment

While creating a migration plan for migration from ESXi to any target, ensure to add at least one vCenter
Server or standalone ESXi host environment for migration.
About this task
Note: This procedure is only applicable for migration from ESXi.
To add a vCenter Server or standalone ESXi host environment, do the following:
Procedure

2. Click + Add Environment under Environments..
The Add Source Environment window appears.
Figure 17: Add VMware ESXi Environment Dialog Box
3. Select VMware ESXi as the environment type.
a. Environment Name: Enter a name for the ESXi environment.

b. vCenter Server or standalone ESX host: Enter the IP address or the FQDN of the vCenter Server, or the
IP address of the ESXi host.
If you do not have a standard port, use the custom port for vCenter in the vCenter IP address:custom port
number format. For example, if you are using IP address, use the format 10.136.72.150:8443 or if you are
using FQDN, use the format vcenter.nutanix.com:8443.
c. User Name: Enter the username for logging on to vCenter Server.
d. Password: Enter the password for logging on to vCenter Server.
The VMware ESXi environment is added to the Move UI and can be viewed in the Environments list in the left
pane of the Move dashboard.
What to do next
You can now add Nutanix AHV cluster environment. For more information, refer to Adding a Nutanix AOS


About this task
allowlist.
Procedure
environment.
the Move dashboard.

What to do next
Creating a Migration Plan (ESXi to ESXi)

migration plan in Move UI without initiating the cutover process.
About this task
Note:
• This procedure is only applicable for migration from ESXi to ESXi.

• If you are logging in for the first time, log on to the Move UI with your default credentials.
• You must have admin user credentials to complete the migration process.
• If you restart the management server, scheduled VM migration does not begin automatically.
• CentOS 7.4 2, 6.8 3, 8, 8.1, 8.2

• Ubuntu 12.04 4, 19.04
• OEL 7 5
• RHEL 6.8, 8.1
• When Move encounters a large source VM disk of size greater than 2 TB that belongs to one ESXi host,
Move prioritize the migration of this disk and does not migrate any other disks from the same host in
parallel. Only after the large VM disk migration gets completed, Move migrates the other disks from the
same host. Meanwhile, Move migrates the VM disks belongs to other source ESXi hosts in parallel.
Procedure

a. Select a Source: Select any vCenter Server or standalone ESXi host source for migration.


b. Select a Target: Select the ESXi target for the migrating VMs.
click Next.
column. The VMs for which migration has failed are not displayed. To show the entire list of VMs, select All
VMs from the drop-down list. To show the configuration of VMs, select Configuration from the drop-down
list. A question mark icon appears beside an unavailable VM, which displays more information about that VM
and might indicate why the VM cannot be migrated.
Note:
• If the source VM has RDM disks in physical compatibility mode, then those disks are converted to
virtual compatibility mode during source VM preparation. By default, power cycle is enabled for
the VMs with physical RDM disks. Move performs the following:
1. Shut down the source VM.
2. Convert physical RDM disks to virtual compatibility mode.
3. Start the VM.
If power cycle is not enabled, then Move converts the physical RDM disks to virtual with VM in
powered on state.
• Migrate VMs retain their power state on the destination cluster.

Alternatively for Linux VMs only, select the Use Private (.PEM) file to authenticate option and upload
the private key for authentication.
Note: If you want to retain the static IP addresses, provide a common set of credentials for your selected
Windows or Linux VMs.
manually run them on the source VMs.
For more information, refer to Manual VM Preparation (ESXi to ESXi) on page 68.
to the next step.
cannot manually select the Mixed option from the Preparation Mode drop-down list.
8. In the Override individual VM Preparation section, click Change Settings to override the same settings for
the individual VMs. You can also update the username and password of the VMs, remove unwanted VMs, or

9. (Optional) In the VM Preparation screen, do one or both of the settings, and then click Next.
b. Bypass Guest Operations on Source VMs: Select this check box to bypass the guest operating system
changes.
d. Settings for individual VMs: Click to change the settings such as retain MAC addresses, bypass guest
operations, and timezone for individual VMs. You can also search the VM by typing the name of the VM
and change the settings.
» Back: Click this option to edit the information.

» Save: Click this option to save the migration plan.
migration plan.
What to do next
Performing a Migration Cutover (ESXi to ESXi) on page 69
Manual VM Preparation (ESXi to ESXi)

You can also prepare the VMs manually by running the scripts provided in the Move UI.
About this task
Note: For running the script, use the Windows built-in administrator credentials for the Windows VMs and use root
user for the Linux VMs.
To manually download and run the migration preparation software, do the following:

Procedure
1. In VM Preparation, select Manual.
2. Run the scripts provided in VM Preparation in the respective source VMs, and then click Next.
These scripts prepare the source VMs by running the IP address retention script.
You can also do the following settings.
a. Change Settings: Click to override the same settings for the individual VMs. You can update the username
and password of the VMs, remove unwanted VMs, or update the VM preparation mode.
b. Retain MAC Addresses from the Source VMs: Select this check box to retain the MAC addresses from
the source VMs.
c. Bypass Guest Operations on Source VMs: Select this check box to bypass the guest operating system
changes.
d. Timezone: Set the timezone as the hardware clock of the VMs in target.
e. Manage Settings for individual VMs: Click to change the settings such as retain MAC addresses, bypass
guest operations, and timezone for individual VMs. You can also search the VM by typing the name of the
VM and change the settings.
f. Schedule Data Seeding: Check this check box to select the date and time for migration.
The VM preparation takes place.
Note: If you have not run the preparation script in the source VM, Move performs data-only migration. For more
information, refer to Performing Data-Only Migration on page 47.

The seeding process for migration begins. You can monitor this information by selecting Status for the migration
plan.
What to do next
Performing a Migration Cutover (ESXi to ESXi) on page 69
Performing a Migration Cutover (ESXi to ESXi)

VMs. You can monitor the VM migration progress by clicking the Status link.

About this task
Note:
• If the initial data seeding finishes in less than 10 minutes, Move continues to wait for 10 minutes to take
the incremental snapshot; however, you can trigger the cutover immediately.
Procedure
2. To perform cutover, select the VMs or group of VMs.
3. Click Cutover.

• Takes the final snapshots for the VM and copying the final changes to ESXi on Nutanix cluster
• Adds a note in the VM in the vCenter
• Creates a VM in the target ESXi on Nutanix cluster
The cutover process begins immediately and takes a few minutes. Once cutover is complete, the VM is ready for
use in the target.
What to do next
Performance Matrix for Large Data Migration (ESXi to ESXi)

Table 20: Performance Numbers of Large Data Migration (ESXi to ESXi)
Total Number Size for Number I/O on the Data Network Migration time taken
Migration of VMs each of Vdisks source churn bandwidth
size Vdisks
Data Cutover
seeding

Total Number Size for Number I/O on the Data Network Migration time taken
size Vdisks
2 TB 1 2 TB 1 No No data 10 G 190 Less than
churn. minutes 5 minutes
1 TB 1 1 TB 1 Yes 10 GB 1G 418 28
minutes minutes

HYPER-V TO AHV AND HYPER-V TO
NUTANIX CLUSTERS ON AWS VM
MIGRATION
You can prepare and migrate VMs running on Hyper-V hypervisor to Nutanix Clusters on AWS and Hyper-V
hypervisor to AHV by using Move.
Note:

Move supports some common operating systems.
Note: The Move UI does not display a message or warning during the creation of a migration plan if you are
attempting to migrate VMs running on an unsupported guest operating systems.
Operating systems Gen 1 Support Gen 2 Support

Windows Server 2019 Yes Yes**
Windows Server 2016 Yes Yes **
Windows Server 2012 R2 Yes Yes **
Windows Server 2012 Yes Yes **
Windows Server 2008 SP2 (32 NA - target NA - source
bit)
bit)
Windows Server 2008 R2 SP1 Yes NA - source
bit)
Windows 7 (32 bit) Yes NA - source
Windows 8 (64 bit) Yes Yes **
Move | Hyper-V to AHV and Hyper-V to Nutanix Clusters on AWS VM Migration | 72

Operating systems Gen 1 Support Gen 2 Support
Windows 10 (64 bit) Yes Yes **
RHEL 6.5–6.9, 7.0–7.7 (64 Yes NA -Target
bit),8.1
CentOS 6.5–6.9, 7.0–7.5 (64 bit), Yes NA -Target
8.0-8.2
Ubuntu 14, 16, 18, 19.04 Yes Yes #
FreeBSD 11 Yes NA - source
Debian 9.4 Yes Not Certified
Oracle 7.x Yes Not Certified

Table 22: Legend
1. Yes. Guest operating system is supported for migration.

2. NA - source. Guest operating system is not supported on Microsoft Hyper-V for given generation.
3. NA - target. Guest operating system is not supported on AHV.
4. Yes **. Generation 2 guest operating system is supported for migration. For Generation 2 VM, during cutover
process, Secure Boot feature is disabled for VM on the added Hyper-V source until cutover is completed. Once
cutover is completed, the setting is reverted on the added Hyper-V source.
Current available versions of AHV do not support Generation 2 VMs directly. Therefore, during the cutover
process, Move automatically runs the following command on a migrated VM on the target cluster.
acli vm.update <vm_id> uefi_boot=True
This command passes the target information, IP address, and credentials to Move. This command might fail due
to the following reasons.
• The added target is Prism Central.

• Unable to SSH to Prism Element with the credentials provided while adding Prism Element as target.
Perform the following manual steps on the target cluster if the migration of a Generation 2 VM fails with the
following error message: Failed to update UEFI flag for <VmName>
1. Shut down the VM.
2. Run the following aCLI command.
acli vm.update <vm_id> uefi_boot=True
3. Start the VM.
After you perform the preceding steps and verify the VM on the target, discard the migration in Move for that
VM.
5. Yes # . In addition to the VM preparation, run the following commands on the source Ubuntu 14 and 16
Generation 2 VMs before migration.
1. Log on to source VM.
2. Change to bash shell.
sudo bash
3. Change the directory.

cd /boot/efi/EFI
4. Copy the files to boot directory.

cp -r ubuntu/ boot
5. Change the directory to boot.

cd boot
6. Rename the file.

mv shimx64.efi bootx64.efi


Operating systems
RHEL 7.7
CentOS 7.3
Requirements
Before attempting to migrate VMs running on Hyper-V using Move, make sure to conform to the
requirements listed here.
Make sure to conform to the following requirements for Hyper-V to Nutanix Clusters on AWS and AHV migration:
• Supported browser: Google Chrome.

• Ensure guest VMs have connectivity with Move.
• Ensure that the guest VMs have integration services installed and IP address is present in the Networking section
of the Hyper-V manager for automatic preparation of the source VMs.
For more information, refer to Manage Hyper-V Integration Services section in the Microsoft documentation for
Hyper-V.
• Ensure WinRM is configured on Hyper-V servers and Windows guest VM and the following inbound and
outbound ports using TCP protocol are enabled for the Windows Remote Management (WinRM) feature to work.
• WinRM-HTTPS: 5986
• WinRM-HTTP: 5985
Note: This requirement is applicable only for automatic VM preparation mode.
Service Accounts
For successful migration of VMs from Hyper-V to AHV and Hyper-V to Nutanix Clusters on AWS, service accounts
for the following must have admin privileges.
• Source Hyper-V Server (standalone or cluster)

• Source VMs planned for migration
A user with administrator role for Windows source VMs or a root user for Linux source VMs to run the
Limitations
This section lists the limitations for migration from Hyper-V to AHV and Hyper-V to Nutanix Clusters on
AWS.
In addition to Migration Limitations on page 12, the support is constrained by the following.

• Migration of guest VMs might fail if you delete an existing user snapshot or checkpoint during the migration.
• VM names with single and double quotes are not supported for migration.
• If VMs are configured with dynamic memory, Move takes only the start-up memory configuration while creating
the target VM on AHV.
• Automatic installation of the Move Hyper-V agent is not supported for Windows Server 2012 (standalone &
cluster).
• VMs protected by Hyper-V replica are not supported.
To allow migration, disable the Hyper-V replication for the required VMs.
Adding Hyper-V Environment

While creating a migration plan for migration from Hyper-V to any target, be sure to add at least one Hyper-
V environment for migration.
About this task
Note: This procedure is only applicable for migration from Hyper-V to Nutanix Clusters on AWS and Hyper-V to
AHV.
To add a Hyper-V environment, do the following:
Procedure
1. Log on to Move UI.

The Add Environment appears.
Figure 21: Add Hyper-V Environment Dailog Box
3. Select Microsoft Hyper-V as the source environment type.

a. Environment Name: Enter a name for the Hyper-V environment.

b. Hyper-V Server: Enter the IP address or FQDN of the Hyper-V source server.
c. Username: Enter a Windows account with administrator privileges of the Hyper-V source server.
d. Password: Enter the password for this Windows account.
Note:
• Hyper-V user account must have administrator privileges.

• Enter cluster IP address (or failover IP address) to discover all clustered VMs from Hyper-V
cluster environment.
• For cluster environment, enter the domain credentials the administrator privileges.
• You must either add the cluster IP address or the standalone IP address of the node.
The Hyper-V environment is added to the Move UI and can be viewed in the Environments list in the left pane
of the Move dashboard.
What to do next
You can also add a Nutanix AHV environment. For more information, refer to Adding a Nutanix AOS Cluster
Environment on page 34

About this task
allowlist.
Procedure

environment.
the Move dashboard.
What to do next
Deploying the Move Agent on Hyper-V Host

You can manually or automatically deploy the Move agent on the source Hyper-V host.
Manual Deployment
To download and install the Move agent on each of the source Hyper-V host machine to support VM discovery and
migrations, do the following:

1. In the Hyper-V host, download move-agent-installer.exe from http://<nutanix-move-ip>/downloads/agents/
move-agent-installer.exe .
Replace <nutanix-move-ip> with the IP address of the Move VM.
2. Go to the location where you have downloaded the agent, and copy or move the downloaded file under C:\users
\Administrator.
3. Launch the command prompt with Run as Administrator to run the following command from C:\users
\Administrator.
move-agent-installer.exe -o [operation] -ip [move ip] -u [user]
Example: move-agent-installer.exe -o install -ip 10.5.244.55 -u user
User can be either a domain or local user with administrator privileges.
Note:
• By default, the Move agent is installed in the user directory. If you want to change the location, use the -
d option.
• To uninstall the Move agent, use the command move-agent-installer.exe -o remove.
• Enter help along with any command for information to display options for that command.
• Move agent service installation will add inbound firewall rule to open port 8087, which is required for
Move VM and Hyper-V interactions. The Move Hyper-V agent service running on Hyper-V uses the
8087 port for interactions with Move. This service requires only the 8087 port and you cannot customize
this service to use any other port.
• Ensure that the service manager console is not opened during installation or removal of the Move agent.
Automatic Deployment
Note:
• Before the deployment, the source Hyper-V server must have WinRM enabled over HTTP or HTTPS.
For more information, refer to Enabling WinRM on page 86.
• Automatic installation of the Move Hyper-V agent is not supported for Windows Server 2012
(standalone and cluster).
• The Move Hyper-V agent service running on Hyper-V uses the 8087 port for interactions with Move.
This service requires only the 8087 port and you cannot customize this service to use any other port.
Move Hyper-V agent is pushed and installed automatically to the Hyper-V source when the Hyper-V server is added
as a source in the Move UI.

migration plan in Move without initiating the cutover process.
About this task
Note:
• This procedure is only applicable for migration from Hyper-V to Nutanix Clusters on AWS and Hyper-
V to AHV.

• CentOS 7.4 2, 6.8 3, 8, 8.1, 8.2

• Ubuntu 12.04 4, 19.04
• OEL 7 5
• RHEL 6.8, 8.1
• The Move UI does not display a message or warning during the creation of a migration plan if you are
attempting to migrate VMs running on an unsupported guest operating systems.
• If you are logging in for the first time, log on to the Move UI with your defaults credentials.
Procedure

a. Select a Source: Select an added Hyper-V source for migration.



b. Select a Target: Select the target for the migrating VMs.
c. Target Container: Select the container on which you will migrate the VMs.
5. In the Select VMs screen, select one or more VMs from the list. To add all the VMs, click the + icon next to
Name, and then click Next.
column.
Note: The VMs for which migration has failed are not displayed. To show the entire list of VMs, select All
VMs from the drop-down list. A question mark icon appears beside an unavailable VM, which displays more
information about that VM and indicates why the VM cannot be migrated.
Note: Migrate VMs retain their power state on AHV.

7. In the VM Preparation screen, under the Preparation Mode drop-down, select Automatic. You can also
select one of the following VM preparation modes.
this option, refer to Automatic VM Preparation for Hyper-V on page 84.
» Manual. Move displays the VM preparation scripts for Windows and Linux VMs. To manually download
and run migration preparation software, select this option, and then run the scripts provided in VM
Preparation on the respective guest VMs.
Note: This step is a mandatory. Do not start the VM migration if the script execution fails.
Ensure the following.
• If you are preparing the VM one more time, the C:\Nutanix folder must not be present on the
guest Windows VM before running the VM preparation scripts.
• The guest VM must be reachable from Move.
• Run the preparation scripts with administrator or root permissions.
These scripts prepare the VMs by installing Nutanix VirtIO device drivers.
By default, Retain Static IP feature is enabled. If you want to disable this feature, change the last argument
of the command to $false, and then the run script.
to step 8.
cannot manually select the Custom option from the Preparation Mode drop-down list.

b. Timezone: Set the timezone as the hardware clock of the VMs in target.
c. Manage Settings for individual VMs: Select to change the settings such as retain MAC addresses,
bypass guest operations, and timezone settings for individual VMs. You can also search the VM by typing
the name of the VM and change the settings.
d. Schedule Data Seeding: Check this check box to select the date and time for migration.
» Back: Click this option to edit the information.

» Save: Click this option to save the migration plan.
migration plan.
What to do next
Automatic VM Preparation for Hyper-V

You can automate the guest VM preparation.
Before you begin

General prerequisites
• The VM IP address must be present in the Hyper-V manager in the Networking section.
If the IP address is not present, then check the Hyper-V integration services status.
• Guest VM must be reachable from the Move VM.
Prerequisites for Windows guest VMs
• WinRM should be configured on the guest VM.

For more information, refer to Enabling WinRM on page 86.

• The credentials provided must have administrator privileges.
• Make sure that the folder c:\Nutanix is not present on the guest VM before initiating the migration if the user is
preparing the VM one more time.
Prerequisites for Linux guest VMs
• SSH service should be up and running.

• The credentials provided must have root or sudo user permission.
• Guest VM should have curl utility installed.
About this task
Note:
• For powered off guest VM, Move does not validate the guest VM credentials in the preparation phase.
The credentials are validated during the migration phase. If the credentials are incorrect, then you cannot
retry the migration of the guest VM. You must discard the migration of the guest VM.
• If UAC is enabled or the automatic VM preparation fails for certain VMs, you can choose to use manual
preparation to prepare such VMs.
For more information about manual VM preparation, refer to Creating a Migration Plan on page 79.
To automatically prepare the VMs, do the following:
Procedure
1. In the Preparation Mode drop-down, select Automatic.

2. Complete the fields in Credentials for Source VMs. If VMs in the migration plan have same credentials, then
enter the user name and password for the guest VMs to allow Move to install the necessary drivers.

a. Override Individual VM Settings: Click to override the same settings for the individual VMs. You can
update the username and password of the VMs, remove unwanted VMs, or update the VM preparation mode.
b. Retain MAC Addresses from the Source VMs: Select this check box to retain the MAC addresses from
the source VMs.
d. Manage Settings for individual VMs: Select to change the settings such as retain MAC addresses, bypass
guest operations, and timezone settings for individual VMs. You can also search the VM by typing the name of
the VM and change the settings.
The credentials of VMs are validated. Once the validation is successful, the Guest Tools are downloaded and
installed in all the VMs of the migration plan. Then, the VMs are validated for readiness.
Note: If the validation of credentials or Guest Tools installation fails, you can update the credentials or remove the
VM from the migration plan and proceed by clicking Next.
What to do next
Enabling WinRM
Enable WinRM to install the Guest Tools on Windows Hyper-V VMs.
About this task
Note:
• This method is a prerequisite for automatic VM preparation to work with Windows Hyper-V VMs.
• Ensure that the ingress ports 5985 and 5986 are enabled.
To enable WinRM, do the following:
Procedure
1. Open PowerShell in Windows VM.
2. Run the script to enable WinRM for Windows Hyper-V VMs.

> winrm quickconfig -q
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="300"}'
winrm set winrm/config '@{MaxTimeoutms="1800000"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'

winrm set winrm/config/service/auth '@{Basic="true"}'
netsh advfirewall firewall add rule name="WinRM 5985" protocol=TCP dir=in localport=5985
action=allow
action=allow
net stop winrm

cmd /c 'sc config winrm start= auto'
net start winrm
3. Run the script to enable Secure Sockets Layer (SSL).

> $c = New-SelfSignedCertificate -DnsName "$(hostname)" -CertStoreLocation cert:\LocalMachine
\My
winrm create winrm/config/Listener?Address=*+Transport=HTTPS
"@{Hostname=`"$(hostname)`";CertificateThumbprint=`"$($c.ThumbPrint)`"}"
Performing Data-Only Migration

When you select Automatic preparation mode while creating a migration plan, you can perform data-only
migration either by bypassing the guest operations or without providing the credentials while preparing a
migration plan. When you select Manual preparation mode while creating a migration plan, do not run the
preparation script in the source VMs to perform data-only migration.
About this task
Note: Data-only migration is only supported from ESXi to AHV and ESXi to Nutanix Cluster on AWS, and Hyper-V
to AHV and Hyper-V to Nutanix Cluster on AWS migrations.
To perform data-only migration, do the following:

Procedure
1. In the VM Preparation screen, if you select Automatic, then proceed without providing the credentials for the
source VMs or select the Bypass Guest Operations on Source VMs check box or if you select Manual, do
not run the preparation script in the source VMs.
The following message appears when the Automatic preparation mode is selected,
Figure 25: OS Credentials Dialog Box
2. Click Continue.
Move migrates the VMs data and creates a VM in the target, and bypasses the operating system operations.

VMs in the AHV cluster. You can monitor the VM migration progress by clicking the Status link.
About this task
Note:
• If the initial data seeding finishes in less than 10 minutes, the Move continues to wait for 10 minutes to
take the incremental snapshot; however, you can trigger the cutover immediately.
• For cutover of Hyper-V source VMs, it is recommended to go with maximum 30 VMs at a time.
To perform a cutover, do the following:

Procedure
2. Select the VMs or group of VMs to cut over.
3. Click Cutover.

• Takes the final snapshots for the VM and copying the final changes to AHV after the last 10 minute interval
• Adds a note in the VM in the Hyper-V manager
• Creates a VM in the target AHV cluster
The cutover process begins immediately and might take a few minutes. Once cutover is complete, the VM is ready
for use in the new AHV cluster.
What to do next

Table 24: Performance Numbers of Large Data Migration (Hyper-V to AHV)
Total Number Size of Number I/O on the Data Network Migration time taken
size Vdisks
Data Cutover
seeding
2 TB 1 2 TB 1 No No I/O 10 G 430 Less than
minutes 5 minutes
2 TB 1 1 TB 2 No No I/O 10 G 260 Less than
minutes 5 minutes
2 TB 1 512 GB 4 No No I/O 10 G 215 Less than
minutes 5 minutes
minutes 5 minutes
minutes 5 minutes

AWS TO AHV AND AWS TO NUTANIX
CLUSTERS ON AWS VM MIGRATION
You can prepare and migrate AWS EC2 instances to Nutanix Clusters on AWS and AWS EC2 instances to AHV by
using Move.
Note:

Move supports some common operating systems. Unless otherwise specified, Nutanix has qualified the following 64-
bit guest operating system versions.
Fully Supported
Note: Some of the operating systems do not support AWS System Manager and thereby cannot used for Automatic
preparation. These are marked for Manual preparation only in the following list:
• Windows 7, 8, 8.1, 10 (Manual preparation only)

• RHEL 6.3 (32-bit and 64-bit supported) (Manual preparation only), 6.5-6.10, 7.0–7.7, and 8.1
• Ubuntu Server 12.0.4, 18.04, 19.04 (Manual preparation only)
• SUSE 11 SP3/SP4 (Manual preparation only), SUSE 12, SUSE 12 SP1 / SP2 / SP3 / SP4
• Oracle Linux 6.4 and later (Manual preparation only), 7.5-7.9
Note: If you face kernel panic issue on Oracle Linux versions after migration to AHV, then refer and apply the KB
article 000004604 for these Oracle Linux VMs.
• Debian 9.4
Move | AWS to AHV and AWS to Nutanix Clusters on AWS VM Migration | 90

Requirements
Before attempting to migrate VMs running on AWS using Move, make sure to conform to the requirements
listed here.
Ensure to conform to the following requirements for AWS EC2 instances to Nutanix Clusters on AWS and AWS EC2
instances to AHV migration.

• Ensure that you enable all outbound ports in the source VM.
• Ensure TCP 443 connection to AWS endpoint for operations in AWS.
• For Windows source VMs, ensure to disable UAC for Windows administrator user.
• For Linux source VMs, ensure that the VM has Internet connectivity during initial preparation to download the
required packages. Install the following packages along with their dependencies: wget, curl, jq, bash, sudo.
• For automated guest preparation, make sure that the guest VM has enabled and is managed by the AWS SSM
Agent.
• The AWS account provided while adding an AWS source must have the set of permissions as provided in the
following JSON to do end-to-end migration of an EC2 instance.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:SimulatePrincipalPolicy",
"ec2:CreateSnapshots",
"ec2:DeleteSnapshot",
"ec2:*Describe*",
"ec2:*KeyPair*",
"ec2:RunInstances",
"ec2:TerminateInstances",
"ec2:StopInstances",
"ec2:CreateSecurityGroup",
"ssm:DescribeInstanceInformation",
"ec2:StartInstances",
"ec2:DeleteVolume",
"ec2:AttachVolume",
"ec2:DetachVolume",
"ec2:CreateTags",
"ec2:DeleteTags",
"ec2:ModifyInstanceAttribute",
"iam:GetUser",
"gamelift:DescribeEC2InstanceLimits",
"ebs:ListSnapshotBlocks",
"ebs:ListChangedBlocks",
"ebs:GetSnapshotBlock",
"ssm:SendCommand",
"ssm:GetCommandInvocation"
],
"Resource": "*"
}
]

}
Service Accounts
For successful migration of VMs from AWS EC2 instances to Nutanix Clusters on AWS and AWS EC2 instances to
AHV, Move requires the following.

• An administrator for Windows source VMs or a root for Linux source VMs to run the source VM
preparation scripts.
Qualified Metrics
The section lists the qualified metrics for migration from AWS EC2 instances to Nutanix Clusters on AWS
and AWS EC2 instances to AHV.
Qualified Metrics for Migration from AWS

The following metrics are qualified for migration from AWS.
• Migration of VMs using all EC2 instance type.
Note: You cannot migrate EC2 instances with more than 40 disks.
• Migration of large VMs, VMs with active workloads, and combination of Windows and Linux VMs with multiple
disks
• Migration of VMs from 13 different regions in parallel using single Nutanix-Move
• Migration plan with five instances each having 13 disks in parallel
• Single migration having two instances with 500 GB disk
• Migration of more than 10 VMs in a plan

• Virtual Private Cloud (VPC) Endpoint for S3 is required for preparation of instances without internet access.
For more information about VPC endpoint for S3, refer to VPC Endpoint for Amazon S3.
Also, to use automatic preparation, these instances needs to be managed by Amazon Web Services Systems
Manager (AWS SSM) using VPC endpoint for Systems Manager.
For more information about VPC endpoint for Systems Manager, refer to VPC endpoint for Systems Manager.
These instances can only be migrated from the following regions where Move has S3 buckets deployed.
• af-south-1
• ap-east-1
• ap-northeast-1
• ap-northeast-2
• ap-south-1
• ap-southeast-1
• ap-southeast-2
• ca-central-1
• eu-central-1
• eu-north-1
• eu-south-1
• eu-west-1
• eu-west-2
• eu-west-3
• me-south-1
• sa-east-1
• us-east-1
• us-east-2
• us-west-1
• us-west-2
• Time required to create the first snapshot for large disks is longer. Depending on the size of the volumes, it can
take several hours (up to 24 hours) for the AMI-creation process to complete.
This section lists the unsupported features for migration from AWS EC2 instances to Nutanix Clusters on
AWS and AWS EC2 instances to AHV.
• Guest operating systems other than the supported operating systems.

For more information, refer to Supported Guest Operating Systems for AWS Migration
• Migration of VMs with EFS backed storage.
Note: Move currently supports migration of VMs with EBS backed storage.

• IP address and MAC address retention.
• Certain types of spot instances (created using non-persistent spot requests) cannot be stopped. When you perform
a cutover for a spot instance, the instance does not stop and the cutover snapshot includes all the changes up to the
point when the cutover snapshot is taken. Any IOs after this point are not available on the target machine.
Limitations
The section lists the limitations and qualified metrics for migration from AWS.
AWS EC2 instances to Nutanix Clusters on AWS and AWS EC2 instances to AHV
The support for migration is constrained by the following.
• Migrations of VMs with Instance Store Volumes are supported. Instance Store Disks are not migrated in this
migration.
Internet connectivity between AWS and on-prem datacenter.
on)
Adding an AWS Environment

While creating a migration plan, if you need to add an AWS source or target, you have to add at least one
AWS environment for migration.
About this task
Note: This procedure is only applicable for migration to and from an AWS environment.
To add an AWS environment, do the following:
Procedure

Figure 26: Add AWS Environment Dialog Box
3. Select Amazon Web Services as the source environment type.
a. Source Name: Enter a name for the AWS environment.

b. AWS Access Key ID: Enter the access key ID of the AWS account.
c. AWS Secret Access Key: Enter the key for logging on to AWS account.
The source environment is added to Move UI and can be viewed in the Environments list in the left pane of the
Move dashboard.
What to do next
You can add a Nutanix AOS cluster environment. For more information, refer to Adding a Nutanix AOS

About this task
allowlist.

Procedure
environment.
the Move dashboard.
What to do next
information, refer to Creating a Migration Plan on page 35 or Creating a Migration Plan on page 79 or Creating
a Migration Plan on page 97 or Creating a Migration Plan (AWS to ESXi) on page 111 or Creating a
Migration Plan (ESXi to ESXi) on page 64

About this task
Note:
• This procedure is only applicable for migration from AWS EC2 instances to Nutanix Clusters on AWS
and AWS EC2 instances to AHV.
• In case of upgrade if the AWS provider is already present then you need to update the required AWS
permissions. You can get these permissions from the Move User Guide and update it on AWS.
Alternatively, you can also remove the AWS provider and try adding it back again. The attempt to add
the AWS provider again will fail due to insufficient permissions, however, the list of new permissions is
provided for you to update on AWS.
• For ongoing migrations from AWS to AOS, ensure the migration is in completed state or complete the
migration before performing the upgrade. Also, terminate the existing NTNX-MOVE-AGENT in the
AWS region after the migration is completed.
• For AWS migrations, Move relies on the power state to identify if a VM is migratable. So, it is
recommended that the VMs are started to check the correct status of migration.
• You can change the protocol from TCP to KCP for better performance if the migration is performed
on an unreliable network (packet loss) for AWS migrations. For more information about changing the
protocol, refer to Changing Default TCP to KCP Protocol of Move on page 150.
• On your first logon, you can log on to the Move UI with your defaults credentials
Procedure

Note: You might at times see a message relating to inventory collection as shown below. During this time, the
environments undergoing Refresh will not be available for selection. Such environments do not automatically
show up for selection once the inventory collection is over. In case you wish to select one of the environments
undergoing Refresh (not available for selection), you will need to select Cancel and wait for inventory collection
to get over and then create the migration plan again.

a. Select a Source: Select any AWS source for migration.

b. Region: Select a region from where you will migrate the VMs.
c. Select a Target: Select the target for migrating the VMs.
d. Target Container: Select the container on which you will migrate the VMs.
click Next.
column.
Note: The VMs for which migration has failed are not displayed. To show the entire list of VMs, select All VMs
from the drop-down list. To show the configuration of VMs, select Configuration from the drop-down list. A
question mark icon appears beside an unavailable VM that displays more information about that VM and indicate
the reason of a failed VM migration.
Note: Migrated VMs retain their power state on the destination cluster.

» Automatic. Move automatically runs scripts on the source VMs to prepare them for migration. Ensure that
guest VM instance has enabled and is managed by the AWS SSM Agent.
For more information, refer to Automatic VM Preparation on page 101
For more information on AWS SSM Agent, refer to Working with SSM Agent.
and run the migration preparation software, select Manual, and then run the scripts provided in the VM
Preparation screen on the respective source EC2 instance.
These scripts prepare the instance by performing the NTNX VirtIO driver installation.
to the step 8.
a. Timezone: Set the timezone as the hardware clock of the VMs in target.
b. Settings for individual VMs: Click to change the timezone settings for individual VMs. You can also
search the VM by typing the name of the VM and change the settings.
c. Schedule Data Seeding: Check this check box to select the date and time for migration.

migration plan.
What to do next
Automatic VM Preparation
About this task
Note: For automatic Windows VM preparation, ensure the guest VM instance is managed by the AWS SSM Manager
and the IAM profile on the instance should have the permissions mentioned in the following json. Alternatively, you
can use the IAM profile provided by AWS Name "AmazonEC2RoleforSSM" and compare that with these permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation",
"ssm:GetDeployablePatchSnapshotForInstance",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:GetManifest",
"ssm:GetParameters",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
"ssm:PutInventory",
"ssm:PutComplianceItems",
"ssm:PutConfigurePackageResult",
"ssm:UpdateAssociationStatus",
"ssm:UpdateInstanceAssociationStatus",
"ssm:UpdateInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2messages:AcknowledgeMessage",
"ec2messages:DeleteMessage",
"ec2messages:FailMessage",
"ec2messages:GetEndpoint",
"ec2messages:GetMessages",
"ec2messages:SendReply"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstanceStatus"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ds:CreateComputer",
"ds:DescribeDirectories"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts",
"s3:ListBucket",
"s3:ListBucketMultipartUploads"
],
"Resource": "*"
}
]
}
Procedure

Ensure that the guest VM instance has enabled and is managed by the AWS SSM Manager.
a. Change Settings: Click to override the same settings for the individual VMs. You can remove unwanted
VMs or update the VM preparation mode.
c. Settings for individual VMs: Click to change the timezone settings for individual VMs. You can also
What to do next

VMs in the AHV cluster. You can monitor the VM migration progress by clicking the Status link.
About this task
Note:
To perform a migration cutover, do the following:
Procedure
2. To perform the cutover, select the VMs or group of VMs.
3. Click Cutover.
• Shuts down the instance

• Takes the final snapshots for the instance and copying the final changes to AHV
• Creates a VM in the target AHV cluster
• Attaches the replicated drives to the VM
for use in the new AHV cluster.
What to do next

Table 25: Performance Numbers of Large Data Migration (AWS to AHV )
Total Data churn Region Target First Migration time taken Platform
migration used network snapshot
size bandwidth creation
time
Data Cutover
seeding
150 G No us-west-2 10 G NA 52 minutes Less than 4 NX-1065
to US minutes
onprem
Cluster
1 TB No us-west-2 10 G 6 hours 3 hours 50 Less than 9 NX-1065
to US minutes minutes
onprem
Cluster
1 TB with 3 5 GB us-west-1 10 G 2 hours 28 1 hour 38 Less than NX-1065
vDisks to US minutes minutes 24 minutes
onprem
Cluster
AWS TO ESXI VM MIGRATION
You can prepare and migrate AWS EC2 instances to ESXi by using Move.
Note: ESXi as a target refers to ESXi running on Nutanix appliances.
Supported Guest Operating Systems (AWS to ESXi)

Fully Supported
Note: Some of the operating systems do not support AWS System Manager and thereby cannot used for Automatic
preparation. These are marked for Manual preparation only in the following list:
• Windows 7, 8, 8.1, 10 (Manual preparation only)

• RHEL 6.3 (32-bit and 64-bit supported) (Manual preparation only), 6.5-6.10, 7.0–7.7, and 8.1
• Ubuntu Server 12.0.4, 18.04, 19.04 (Manual preparation only)
• SUSE 11 SP3/SP4 (Manual preparation only), SUSE 12, SUSE 12 SP1 / SP2 / SP3 / SP4
• Oracle Linux 6.4 and later (Manual preparation only), 7.5-7.9
• Debian 9.4
Requirements (AWS to ESXi)

Before attempting to migrate VMs running on AWS using Move, make sure to conform to the requirements
listed here.
Ensure to conform to the following requirements for AWS to ESXi migration.
• Supported browser: Google Chrome.

Move | AWS to ESXi VM Migration | 105

• For Linux source VMs, ensure that the VM has Internet connectivity during initial preparation to download the
required packages. Install the following packages along with their dependencies: wget, curl, jq, bash, sudo.
• For automated guest preparation, make sure that the guest VM has enabled and is managed by the AWS SSM
Agent.
• The AWS account provided while adding an AWS source must have the set of permissions as provided in the
following JSON to do end-to-end migration of an EC2 instance.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateSnapshots",
"ec2:*Describe*",
"ec2:*KeyPair*",
"ec2:RunInstances",
"ec2:DeleteVolume",
"ec2:AttachVolume",
"ec2:DetachVolume",
"ec2:CreateTags",
"ec2:DeleteTags",
"iam:GetUser",
"gamelift:DescribeEC2InstanceLimits",
"ebs:ListSnapshotBlocks",
"ebs:ListChangedBlocks",
"ebs:GetSnapshotBlock",
"ssm:SendCommand",
"ssm:GetCommandInvocation"
],
"Resource": "*"
}
]
}
Service Accounts
For successful migration of VMs from AWS to ESXi, Move requires the following.
• Prism Web Console UI for the ESXi cluster

Qualified Metrics (AWS to ESXi)

The section lists the qualified metrics for migration from AWS.
The following metrics are qualified for migration from AWS.

• Migration of VMs using all EC2 instance type.
Note: You cannot migrate EC2 instances with more than 40 disks.
• Migration of large VMs, VMs with active workloads, and combination of Windows and Linux VMs with multiple
disks
• Migration of VMs from 13 different regions in parallel using single Nutanix-Move
• Migration plan with five instances each having 13 disks in parallel
• Single migration having two instances with 500 GB disk
• Migration of more than 10 VMs in a plan
• Virtual Private Cloud (VPC) Endpoint for S3 is required for preparation of instances without internet access.
For more information about VPC endpoint for S3, refer to VPC Endpoint for Amazon S3.
Also, to use automatic preparation, these instances needs to be managed by Amazon Web Services Systems
Manager (AWS SSM) using VPC endpoint for Systems Manager.
For more information about VPC endpoint for Systems Manager, refer to VPC endpoint for Systems Manager.
These instances can only be migrated from the following regions where Move has S3 buckets deployed.
• af-south-1
• ap-east-1
• ap-northeast-1
• ap-northeast-2
• ap-south-1
• ap-southeast-1
• ap-southeast-2
• ca-central-1
• eu-central-1
• eu-north-1
• eu-south-1
• eu-west-1
• eu-west-2
• eu-west-3
• me-south-1
• sa-east-1
• us-east-1
• us-east-2
• us-west-1
• us-west-2

• Time required to create the first snapshot for large disks is longer. Depending on the size of the volumes, it can
take several hours (up to 24 hours) for the AMI-creation process to complete.
Unsupported Features (AWS to ESXi)

This section lists the unsupported features for migration from AWS.

• Migration of VMs with EFS backed storage.
Note: Move currently supports migration of VMs with EBS backed storage.
• IP address and MAC address retention.

• Certain types of spot instances (created using non-persistent spot requests) cannot be stopped. When you perform
a cutover for a spot instance, the instance does not stop and the cutover snapshot includes all the changes up to the
point when the cutover snapshot is taken. Any IOs after this point are not available on the target machine.
Limitations (AWS to ESXi)

The section lists the limitations for migration from AWS.
AWS to ESXi Migration Limitations

• Migrations of VMs with Instance Store Volumes are supported. Instance Store Disks are not migrated in this
migration.
Internet connectivity between AWS and on-prem datacenter.
• Move does not install VMware Tools on the VMs.
on)

About this task
Procedure


Move dashboard.
What to do next

About this task
allowlist.

Procedure
environment.
the Move dashboard.
What to do next
a Migration Plan on page 97 or Creating a Migration Plan (AWS to ESXi) on page 111 or Creating a Migration
Plan (ESXi to ESXi) on page 64

Creating a Migration Plan (AWS to ESXi)
About this task
Note:
• This procedure is only applicable for migration from AWS to ESXi.

• In case of upgrade if the AWS provider is already present then you need to update the required AWS
permissions. You can get these permissions from the Move User Guide and update it on AWS.
Alternatively, you can also remove the AWS provider and try adding it back again. The attempt to add
the AWS provider again will fail due to insufficient permissions, however, the list of new permissions is
provided for you to update on AWS.
• For AWS migrations, Move relies on the power state to identify if a VM is migratable. So, it is
recommended that the VMs are started to check the correct status of migration.
• For ongoing migrations from AWS to AOS, ensure the migration is in completed state or complete the
migration before performing the upgrade. Also, terminate the existing NTNX-MOVE-AGENT in the
AWS region after the migration is completed.
• On your first logon, you can log on to the Move UI with your defaults credentials
Procedure

Figure 33: New Migration Plan

a. Select a Source: Select any AWS source for migration.

b. Region: Select a region from where you will migrate the VMs.
c. Select a Target: Select the target for migrating the VMs.
d. Target Cluster: Select the cluster on which you will migrate the VMs.
e. Target Container: Select the container on which you will migrate the VMs.
click Next.
column.
Note: Migrated VMs retain their power state on the destination cluster.
» Automatic. Move automatically runs scripts on the source VMs to prepare them for migration. Ensure that
guest VM instance has enabled and is managed by the AWS SSM Agent.
For more information, refer to Automatic VM Preparation (AWS to ESXi) on page 114
For more information about AWS SSM Agent, refer to Working with SSM Agent.
manually run them on the source VMs. If you select this option, proceed to step 8.
to the step 8.

a. Timezone: Set the timezone as the hardware clock of the VMs in target.
b. Settings for individual VMs: Click to change the timezone settings for individual VMs. You can also
10. In the Summary screen, choose one of the following, and then proceed to review the VM migration summary.

migration plan.
What to do next
Performing a Migration Cutover (AWS to ESXi) on page 116
Automatic VM Preparation (AWS to ESXi)

About this task
Note: For automatic Windows VM preparation, ensure the guest VM instance is managed by the AWS SSM Manager
and the IAM profile on the instance should have the permissions mentioned in the following json. Alternatively, you
can use the IAM profile provided by AWS Name "AmazonEC2RoleforSSM" and compare that with these permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation",
"ssm:GetDeployablePatchSnapshotForInstance",
"ssm:GetDocument",

"ssm:DescribeDocument",
"ssm:GetManifest",
"ssm:GetParameters",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
"ssm:PutInventory",
"ssm:PutComplianceItems",
"ssm:PutConfigurePackageResult",
"ssm:UpdateAssociationStatus",
"ssm:UpdateInstanceAssociationStatus",
"ssm:UpdateInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2messages:AcknowledgeMessage",
"ec2messages:DeleteMessage",
"ec2messages:FailMessage",
"ec2messages:GetEndpoint",
"ec2messages:GetMessages",
"ec2messages:SendReply"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstanceStatus"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ds:CreateComputer",
"ds:DescribeDirectories"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",

"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"logs:PutLogEvents"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts",
"s3:ListBucket",
"s3:ListBucketMultipartUploads"
],
"Resource": "*"
}
]
}
Procedure
a. Change Settings: Click to override the same settings for the individual VMs. You can remove unwanted
VMs or update the VM preparation mode.
c. Settings for individual VMs: Click to change the timezone settings for individual VMs. You can also
What to do next
Performing a Migration Cutover (AWS to ESXi) on page 116
Performing a Migration Cutover (AWS to ESXi)

VMs in the AOS cluster. You can monitor the VM migration progress by clicking the Status link.

About this task
Note:
To perform a migration cutover, do the following:
Procedure
2. To perform the cutover, select the VMs or group of VMs.
3. Click Cutover.
• Shuts down the instance

• Takes the final snapshots for the instance and copying the final changes to AOS
• Creates a VM in the target AOS cluster
• Attaches the replicated drives to the VM
for use in the new AOS cluster.
What to do next

AHV TO AWS VM MIGRATION
To provide you the flexibility to Move some workloads between private and public cloud, Move has introduced AHV
to AWS migration. You can now prepare and migrate AHV VMs to AWS by using Move.
Note: AHV to AWS migration is a technical preview feature in Move.
Supported Guest Operating Systems (AHV to AWS)

Fully Supported
• Windows Server 2012 R2, 2016

• RHEL 6.8–6.10, 7.3–7.7, 8.1
• CentOS 6.8–6.9, 7.3–7.5, 8.0-8.2
• Ubuntu 14.04, 16.04, 18.04, 19.04
Requirements (AHV to AWS)

Before attempting to migrate VMs running on AHV using Move, make sure to conform to the requirements
listed here.
Ensure to conform to the following requirements for AHV to AWS migration.

• Ensure that you have at least one VPC, which has Internet gateway. Move needs that VPC to deploy the <source-
vm-name>-NTNX-MOVE-AGENT, and then communicate with it.
• Ensure TCP 443 connection to AWS endpoint for operations in AWS.
Requirements for Modules or Drivers

Make sure that the following modules and drivers are installed in Windows, Linux, and AWS VMs:
For Windows:
Move | AHV to AWS VM Migration | 118

• Enable WinRM for automatic preparation.
Ensure to enable the following inbound and outbound ports using TCP protocol for the Windows Remote
Management (WinRM) feature to work.
• WinRM-HTTPS: 5986
• WinRM-HTTP: 5985
• RDP: 3389 (only for inbound)
• SSH: 22
• Install Nutanix Guest Tools (NGT)
For Linux:
• Install Linux-AWS for Ubuntu 14.04, 16.04, 18.04 (apt-get install linux-aws)
• Install Nutanix Guest Tools (NGT)
• SSH should be enabled with root user privilege for automatic preparation
AWS
• The AWS account provided while adding an AWS target must have the set of permissions as provided in the
following JSON to do end-to-end migration.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DetachVolume",
"ec2:AttachVolume",
"ec2:AuthorizeSecurityGroup*",
"ec2:DeleteTags",
"ec2:CreateTags",
"ec2:*Describe*",
"ec2:RunInstances",
"ec2:CreateVolume",
"ec2:DeleteVolume",
"ec2:CreateSnapshot",
"ec2:*KeyPair*",
"iam:GetUser",
"route53:CreateHostedZone",
"route53:UpdateHostedZoneComment",
"route53:GetHostedZone",
"route53:ListHostedZones",
"route53:DeleteHostedZone",
"route53:AssociateVPCWithHostedZone",
"route53:ChangeResourceRecordSets",
"route53:DisassociateVPCFromHostedZone",

"route53:ListResourceRecordSets",
"route53:ListHostedZonesByName",
"route53:GetHostedZoneCount",
"gamelift:DescribeEC2InstanceLimits"
],
"Resource": "*"
}
]
}
Service Accounts
For successful migration of VMs from AHV to AWS, Move requires the following.
• Prism Element for the AHV cluster

Qualified Metrics (AHV to AWS)

The section lists the qualified metrics for migration from AHV to AWS.
The following metrics are qualified for migration from AHV.
• Migration of 10 VMs where each VM has 10 disks in a single migration plan

• Migration of 10 VMs where each VM has 15 disks. These VMs are distributed in five migration plans (each has
two VMs) and all the five migration plans are created in different target AWS regions.
• 1.6 TB VM migration
• 50 VMs migration with three migration plans
Unsupported Features (AHV to AWS)

This section lists the unsupported features for migration from AHV to AWS.

• AHV clusters with protection domain and stretched containers
• VMs with GPUs
• Clusters with encryption enabled
• Clusters with multi-homing setups
• Increasing the disk size of the source VM
• Migration of VMs to the ap-east-1, eu-west-3, eu-north-1, and me-south-1 regions.
• VMs launched by using Amazon Machine Images (AMIs) with product codes
• Migration of non-english VMs, such as Japanese
• IP address and MAC address retention
Limitations (AHV to AWS)

The section lists the limitations for migration from AHV to AWS.

AHV to AWS Migration Limitations
Internet connectivity between on-prem datacenter and AWS.

About this task
allowlist.
Procedure

environment.
the Move dashboard.
What to do next
a Migration Plan on page 97 or Creating a Migration Plan (AWS to ESXi) on page 111 or Creating a Migration
Plan (ESXi to ESXi) on page 64

About this task
Procedure


Move dashboard.
What to do next
Creating a Migration Plan (AHV to AWS)

About this task
Note:
• This procedure is only applicable for migration from AHV to AWS.

• On your first log on, you can log on to the Move UI with your defaults credentials.
Procedure

a. Select a Source: Select any AHV source for
migration.
If you select Prism Central IP address, a new field Select Cluster appears to select any cluster of that PC.

b. Select a Target: Select the target AWS instance for the migrating VMs.
c. Target Region: To migrate the VMs, select a region.
Note: Only regions with Internet gateway VPCs are available for selection.
d. Target Availability Zone: Select a availability zone to create the target instance.
Availability zones are region specific.

click Next.
column.
Note: Migrate VMs retain their power state on the destination cluster.
6. In the Network Configuration screen, select the following fields, and then click Next.
a. Target Network: Select the network that target instance will use after migration.
b. Subnet: Select the subnet for the target network.
c. VPC Network: Select this network to deploy the NTNX-MOVE-AGENT instance to initiate the migration.
For more information, refer to Automatic VM Preparation (AHV to AWS) on page 128.
and run the migration preparation software, select this option, and then run the scripts provided in the VM
Preparation screen on the respective source EC2 instance.
These scripts prepare the instance by performing the following installations.
For Windows: AWS Paravirtualization (PV) driver, AWS EC2Config, and Elastic Network Adapter (ENA)
driver
For Linux: ENA driver and Intel Driver
Note: Ensure to run the VM preparation script on all selected VMs. If not, Move will only migrate VM
data and not start the VM in the target environment. Also, all operating system configuration options will be
bypassed.
prepare one set of VMs manually and prepare another set of VMs automatically in the same migration plan.
to the step 8.

8. In the Override individual VM Preparation section, click Change Settings to override the same settings for
the individual VMs. You can also update the username and password of the VMs, remove unwanted VMs, or
9. (Optional) In the VM Preparation screen, do one or both of the settings, and then click Next.
a. In the Settings for Individual VMs section, click Change Settings to configure AMI IDs and Instance
Type settings for individual VMs.
b. Check the Schedule Data Seeding check box to select the date and time for migration.

Once you save and proceed, the seeding process for migration begins and Move automatically deploys a
lightweight Move agent (<source-vm-name>-NTNX-MOVE-AGENT) in the selected region as an Amazon EC2
instance, which allows to establish a secure connection between Nutanix-Move and the selected UVMs.
Note: This process takes some time.
• For each VM, a new NTNX-MOVE-AGENT is deployed. Following are the configuration of
deployed <source-vm-name>-NTNX-MOVE-AGENT.
1. Name: <source-vm-name>-NTNX-MOVE-AGENT-INSTANCE
For example, centos73-QM-1-NTNX-MOVE-AGENT
Here centos73-QM-1 is the source VM name.
2. Instance Type: t2.micro
3. RAM: 1 GB
4. Storage: 20 GB EBS volume
5. VPC: Default VPC of the region
6. Tags: Name, version, fingerprint
7. Security key: Dynamically created key that is attached to secure Move to <source-vm-
name>-NTNX-MOVE-AGENT communication.
What to do next
Performing a Migration Cutover (AHV to AWS) on page 130

Automatic VM Preparation (AHV to AWS)
About this task
Note:
• Before automatic Windows VM preparation, enable WinRM and enable the ports.
• Automatic VM preparation does not work with the Windows domain account. Use the Windows built-in
administrator credentials for the Windows VMs.
Procedure
2. Complete the fields in Credentials for Source VMs.
a. Enter the user name and password for the guest VMs to allow Move to install the necessary drivers.
b. Use Private (PEM) file to authenticate: Check the Use Private (PEM) file to authenticate check box
to use a key instead of username and password for Linux VMs to allow Move to install the necessary drivers.
3. (Optional) In the VM Preparation screen, do the following, and then click Next.
a. In the Override individual VM Preparation section, click Change Settings to override the same settings
for the individual VMs. You can update the username and password of the VMs, remove unwanted VMs, or
b. (Optional) In the Settings for Individual VMs section, click Change Settings to configure AMI IDs and
Instance Type settings for individual VMs.
What to do next
Performing a Migration Cutover (AHV to AWS) on page 130
Connecting to Move Agent by Using SSH Lite Utility (AHV-AWS)

You can connect to the Move agent (<source-vm-name>-NTNX-MOVE-AGENT) by using the SSH Lite
utility.
About this task
Note: This procedure is only applicable for migration from AHV to AWS.
To connect to <source-vm-name>-NTNX-MOVE-AGENT by using the SSH Lite utility, do the following:

Procedure
1. SSH to the Move VM as an admin user.
2. Switch to the root user by entering the password for the admin user.
[sudo] password for admin:
3. Connect to <source-vm-name>-NTNX-MOVE-AGENT for one or multiple AWS sources of the specific region.
Note: You have to run this command for each of the source VMs.
root@move on ~ $ sshlite --region <region_name> --provider <AWS_source_name> --reverse true

--plan <migration_plan_name> --vm <vm_name>
For example, root@move on ~ $ sshlite --region us-west-1 --provider aws_src --reverse true --
plan plan1 --vm testvm. Here us-west-1 is the region name, aws_src is the AWS source name, plan1 is the
migration plan name, and testvm is the name of the VM.
<source-vm-name>-NTNX-MOVE-AGENT is now connected.
Enabling WinRM (AHV-AWS)

You need to enable WinRM to install the Guest Tools on AHV VMs.
Before you begin

Ensure that the ingress ports 5985 and 5986 are enabled.
About this task
Note: This method is a prerequisite for Automatic VM preparation to work with Windows source VMs.
To enable WinRM.
Procedure
1. Open PowerShell in Windows VM.
2. Run the script to enable WinRM on AHV VMs.

> winrm quickconfig -q
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="300"}'
winrm set winrm/config '@{MaxTimeoutms="1800000"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
action=allow
action=allow
net stop winrm

cmd /c 'sc config winrm start= auto'
net start winrm
3. Run the script to enable Secure Sockets Layer (SSL).

> $c = New-SelfSignedCertificate -DnsName "$(hostname)" -CertStoreLocation cert:\LocalMachine
\My

winrm create winrm/config/Listener?Address=*+Transport=HTTPS
"@{Hostname=`"$(hostname)`";CertificateThumbprint=`"$($c.ThumbPrint)`"}"
Performing a Migration Cutover (AHV to AWS)

When the seeding process is complete, you can cut over the selected VMs to the AWS target.
About this task

You can monitor the VM migration progress by clicking the status link.
Note:
To perform a cutover, do the following:
Procedure
2. To cut over, select the VMs or group of VMs.
3. Click Cutover.

• Takes the final snapshots for the VM and copying the final changes to AWS
• Creates an instance in the AWS target
• Attaches replicated disks to the VM
• Powers on or off the instance (depends on the initial power state)
The cutover process begins immediately and might take a few minutes.
Once the cutover is complete, the AWS instance is available. By default, the security group attached to the
instance has all the ingress traffic blocked. To access the guest VMs, you need to update the security group
according to your requirement.
What to do next

ENVIRONMENTS AND MIGRATION PLAN
MANAGEMENT
You can manage the existing environments and migration plans from the Move dashboard. You can
Refresh, Edit, or Remove an environment and Start, Pause, Resume, Abort, Edit, or Delete the
migration plans.
Basic Actions for Existing Environments

The ellipses icon in the left column of the dashboard includes the following actions that can be performed on any
existing environment:
Figure 39: Actions Button for Environments Management
• Refresh. Refreshes to the latest changes made to the environment.

• Edit. Updates the existing environment.
For editing the environment, refer to Adding Environment section for the respective environment.
• Remove. Removes the existing environment.
Basic Actions for Migration Plans

You can click the name of a migration plan and get an insight of the migrated size, status, and details of the migrated
VMs.
For more information on limits for data sync during migration, refer to Limits for Data Sync during Migration on
page 132.
The Action drop-down in the Status column of the Migration Plans page includes the following actions:
• Start. Starts the already created migration plan. The status changes to Validating Plan, and then to
Migration in Progress. Once the migration is complete, the status changes to Migration Completed.
Note: You cannot edit or delete a migration plan once the migration is started.
• Pause. Pauses the migration that is in progress. The status changes to Migration Paused. This option is only
available once you start a migration plan. When a migration is paused, you can either resume, stop, or delete the
migration.
• Resume. Resumes the paused migration. This option is only available once you pause a migration plan.
Move | Environments and Migration Plan Management | 131

• Abort. Cancels the migration. The status changes to Aborting Migration, and then to Migration
Cancelled. Once the migration is canceled, you can only delete the migration plan, and cannot perform any
other actions on that migration plan.
• Edit. Updates the existing migration plan.
For editing the migration plan, refer to Creating a Migration Plan section for the respective source and target, and
follow the process from Step 4.
• Delete. Deletes the existing migration plan.
Limits for Data Sync during Migration

Move supports concurrent migrations and allows users to create and start the migration of multiple migration plans
in parallel. To ensure the source providers are not overloaded and avoid throttling errors, internally Move maintains
rules to limit the number of concurrent disks (migrations) which can be in data sync phase during migration.
Move allocates its resources to the initial set of disks and once data transfer is completed for one of the disks, it will
pick up the next disk in the queue.
Following are different limits for data transfer and if any of these limits are reached, subsequent transfers of disks are
not started till some of in-progress data transfers complete.
Source Type Limit
Number of Disks per Move Instance 16

Number of Disk per ESxi Host 8
Number of Disk per Provider ( ESX/HyperV) 16
Number of Disk per Provider(AWS) 8
Note: If ongoing migration disk is of size greater than 2 TB, then all other migrations of the same ESXi host will be in
queue.
For example, If 8 VMs with 2 disks each are in the data transfer phase of migration, any newly started migration will
be queued till a slot becomes available. Another example, if 8 disks from a given ESXi host are in data transfer phase,
any new VM migration from that specific host will be queued till one of the disks completes data transfer.
When the VMs are in queue for Data sync and waiting for resources, Move UI shows the VM status as In Queue.
In the following image, migrations started for multiple single disk VMs in parallel. Move started the migration of 8
disks (VMs) in parallel and the rest of VMs are in state In Queue for Resources. For example, VM-10.

Figure 40: Parallel Migration of Single Disk VMs
Move picked up VM-2, VM-3, VM-15, and VM-10 and started data seeding. Once data seeding was completed for
these four VMs, rest of the VMs were in queue. For example, VM-12 is in queue and will wait for the next available
slot.
Figure 41: Status Change of VMs during Parallel Migration

MOVE ADMINISTRATION
You can upgrade, uninstall, and modify the Move configurations.
Move Upgrade Management

You can upgrade to a new version of Move to use the latest available features. The dashboard displays the current
version and an option to upgrade the Move VM to the latest version when a new version is available for upgrade.
Note:
• You can now update to the latest version of Move only from the last two major releases along with the
minor releases during that interval.
For example, for Move 3.7.0, update is supported from Move 3.5.0, 3.5.1, 3.5.2, 3.6.0, 3.6.1, and 3.6.2.
• It is rarely observed that upgrade from 3.2.0 proceeds even though it is not allowed and restricted. Note
that the preceding upgrade flow is not supported.
You can upgrade Move in the following two ways:
• Online Upgrade - If the Move VM is already connected to the Internet, the system automatically detects the latest
version and you can perform the one-click upgrade operation or you can upgrade by using the CLI
For more information, refer to Upgrading Move Online (1-Click Method) on page 134 or Upgrading Move
Online (CLI) on page 136.
• Offline Upgrade - If the Move VM is not connected to the Internet, you can upgrade the server in offline mode by
uploading the binary or by performing the manual CLI upgrade operation.
For more information, refer to Upgrading Move Offline (Uploading Binary) on page 137 or Upgrading Move
Offline (CLI) on page 139.
Note:
• Both online and offline upgrade require some application downtime to ensure that Move lose no data
during the upgrade.
• If upgrade fails due to any reason, you have to do a fresh installation.
• To reset the upgrade state of the updater container, run the following command:
updater-op -t -r -y
Online Upgrade
If the Move VM is already connected to the Internet, the system automatically detects the latest version and you can
perform the one-click upgrade operation or you can upgrade by using the CLI.
Upgrading Move Online (1-Click Method)

You can upgrade Move to the latest available version by using the 1-click upgrade method.
Before you begin

If the Move VM is deployed behind the firewall, online update will not work and you will also not receive the
update notifications. To perform an online upgrade and to receive the update notifications, add the firewall
Move | Move Administration | 134

rules to accept the IP addresses of the following URLs. You can also use the nslookup command to get
the list of IP addresses.
• auth.docker.io
• registry-1.docker.io
• index.docker.io
About this task

To upgrade Move, do the following:
Procedure
1. Log on to the Move UI by using a supported web browser.
2. In the gear icon drop-down list, click Upgrade Software.
Figure 42: Settings Menu: Upgrade Software
The Upgrade dialog box displays the latest available version of Move. Also, a notification New Update
Available appears.
Figure 43: Upgrade Dialog Box
3. Click Upgrade.
A confirmation message is displayed after the upgrade is complete.

4. Log on again to access the updated version of Move.
Upgrading Move Online (CLI)

You can upgrade the Move VM by using CLI.
Before you begin

If the Move VM is deployed behind the firewall, online update will not work and you will also not receive the
update notifications. To perform an online upgrade and to receive the update notifications, add the firewall
rules to accept the IP addresses of the following URLs. You can also use the nslookup command to get
the list of IP addresses.
• auth.docker.io
• registry-1.docker.i
• index.docker.io
About this task
Note: The upgrade installer is available in the Move software package Move ZIP file for AHV.
Procedure
1. Download the Move upgrade installer Move ZIP file for AHV from Nutanix Support Portal.
$ ./binary_name -i vm_ip_address
Replace vm_ip_address with the VM IP address.
5. Enter the username nutanix and the password nutanix/4u, and then press Enter.
6. Update the software.

(Nutanix Move)>> software update
The CLI displays a Complete confirmation.
Note: Update process takes several minutes.
Offline Upgrade
If the Move VM is not connected to the Internet, you can upgrade the VM in offline mode by uploading the binary or
by performing the manual CLI upgrade operation.

Note: You can perform offline upgrades from Move 3.1.0 version onward. Offline upgrades from 3.0.3 and earlier
versions are not supported.
Upgrading Move Offline (Uploading Binary)

You can upgrade Move VM to the latest available version without connecting to the Internet by uploading
the binary.
Before you begin

When you are connected to the Internet, you must download the Move offline upgrade package from
Nutanix Support Portal, and unzip it to keep the move-offline-upgrade-x.x.x.x.tar.gz binary file and
the update_info.json metadata file. Here, x.x.x.x is the version number of the file.
About this task

Procedure
1. Log on to the Move UI by using a supported web browser.

2. In the gear icon drop-down list, click Upgrade Software.
Figure 44: Settings Menu: Upgrade Software
The Upgrade dialog box displays the latest available version of Move and a section to perform an offline
upgrade by uploading the binary file. Also, a notification New Update Available appears.
Figure 45: Upgrade Dialog Box
3. Under Upload Upgrade Software Binary section, click Upload the Binary.
An Upgrade page appears to choose the binary file and metadata file

4. Click Choose to select the downloaded binary and metadata file.
Figure 46: Upload Software Binary for Upgrade
5. Click Upload, and then click Upgrade.

The binary and metadata files are now uploaded and upgrade is performed.
6. Log on again to access the updated version of Move.
Upgrading Move Offline (CLI)

You can upgrade Move offline by using CLI.
About this task
Note:
• The offline upgrade installer is available in the Move Offline Upgrade Package
• Update process takes several minutes.
Procedure
1. Download the Move offline upgrade installer Move Offline Upgrade Package from Nutanix Support Portal. Click
Entity menu > Downloads > Nutanix Move.

$ ./binary_name -i VM_ip_address
For more information, refer to Move Software Package on page 8 .
Replace VM_ip_address with the VM IP address.
5. Enter the username nutanix and the password nutanix/4u, and then press Enter.
6. Update the software.

(Nutanix Move)>> software offlineUpdate
The CLI displays a Complete confirmation.
Undeploy Move
You can undeploy Move by undeploying the VM through the CLI or deleting the VM from Prism Element UI.
Note: Nutanix recommends undeploying Move with the CLI instead of deleting the Move VM. This action allows
Move to automatically clean the NFS allowlist exceptions created during the Move deployment.
Undeploy Move (CLI)

You can undeploy Move by undeploying the VM through the CLI.
About this task

To undeploy the Move VM by using the CLI, do the following:
Procedure
2. Browse to the deployment utility folder location and run the deployment utility.
$ binary_name -c cluster-virtual_ip_address
Replace cluster-virtual_ip_address with the FQDN or the IP address of the cluster.
3. Log on to the Prism Element with the admin user credentials.
4. To undeploy the Move VM, run the following command and when prompted for confirmation, enter Y:
admin@pevm$ undeploy-vm
Note: The name of the Move VM must be Nutanix-Move; otherwise, the following command fails.
The Move VM undeploy can take a few minutes.

Undeploy Move (Prism Element UI)
You can undeploy Move by deleting the VM from Prism Element UI.
About this task

To delete the Move VM from the cluster, do the following:
Procedure
1. Log on to the Prism Element UI of the cluster with the admin user credentials where Move VM is deployed.
2. Go to Entity menu > Virtual Infrastructure > VMs .
3. Click List tab from the left navigation.
4. Select the VM name Nutanix-Move.
5. Click Actions, and then click Delete.

The Move VM is deleted from the cluster.
Changing the Database Password

Nutanix recommends that you secure your database by changing the password of the database.
About this task

To change the password of your database, do the following:
Procedure
1. Open the Move CLI.
2. Run the following command as the root user, and then press Enter.
root@move on ~ $ chdbpasswd
The following message appears. Changing the postgresql DB password for user 'admin'
and database 'datamover'. WARNING: This operation will restart postgresql and
mgmtserver services.
3. Type the password and press Enter.

New password:
4. Confirm the password and press Enter.

Retype new password:
Writing updated config to file: /opt/xtract-vm/resources/config.toml
Restarting postgresql and mgmtserver to reflect the password change...
The password is updated successfully and the new password is stored in /resources/config.toml.

5. Verify if the password has changed.
a. Move to the Docker container of the management server.

root@move on ~ $ mgmtserver-shell
b. Move to the resources directory.

root@move on ~ $ cd resources
c. Open the config.toml file to verify if the password is changed.
Configuring Time-Out for Source Inventory Refresh

You can change the default time-out and configure a new time-out for source inventory refresh.
About this task

To configure a time-out for source inventory, do the following:
Procedure
1. Log on to the Move CLI.
2. Switch to the root user by entering the password of the Move VM.
3. In the command line, run the following command.

root@move on ~ $ vi /opt/xtract-vm/bin/docker-compose.yml
4. In the file, go to services > srcagent > environment, add the following line.
- VC_INV_TIMEOUT_MINS=10
5. Save and exit the file.
6. Restart the source agent service.

root@move on ~ $ docker restart bin_srcagent_1
7. Refresh the inventory.
8. Verify the changes in the srcagent log.

MOVE TROUBLESHOOTING
This section guides you through the troubleshooting steps for some of the issues you might face while
using Move.
Move Support Bundle Collection

You can generate and download a support bundle that you can send to Nutanix Support for assistance. Support bundle
contains a collection of logs from the following sources:
• Nutanix-Move
• NTNX-MOVE-AGENT VMs connected to Nutanix-Move
• Guest VMs, which are connected to NTNX-MOVE-AGENT VMs.
Note: NTNX-MOVE-AGENT VMs and Guest VMs logs will only be present in the Move version less than 3.7.0.
• Nutanix-Move Hyper-V agent logs
Note:
• Logs for stopped or discarded UVMs are not collected in the support bundle.
• From Move 1.1.3 release, the support bundle includes the ping statistics of the source ESXi hosts and
target AHV hosts.
Downloading Support Bundle (UI)

You can generate and download a support bundle from the Move dashboard that you can send to Nutanix
Support for assistance.
About this task

To download the support bundle from Move UI, do the following:
Procedure
Move | Move Troubleshooting | 143

2. Click the gear icon from the Move dashboard, and then click Download Support Bundle.
Figure 47: Support Bundle Download
Note: Download might take a few moments to begin.
A diagnostic bundle is generated and downloaded as move-support-bundle.<date-of-

download>-<version_number>.tar.gz.
Downloading Support Bundle (CLI)

You can generate and download a support bundle from the Move CLI that you can send to Nutanix Support
for assistance.
About this task

To download the support bundle from Move CLI, do the following:
Procedure
1. Log on as root user into the Move VM.
2. To download the support bundle, run the following command:

root@move on ~ $ /opt/xtract-vm/bin/support-bundle
Note: Download might take a few moments to begin.
A diagnostic bundle is generated under the current directory or the path you specified to the support-bundle
script.
Accessing Move VM with SSH

You can SSH into the Move VM.
About this task

To SSH into the Move VM, do the following:

Procedure
1. Open up an SSH terminal program.

SSH terminal program such as Terminal on the Mac or PuTTY on Windows
.
2. In Terminal, to SSH to the Move VM run the following command.

$ ssh <move_vm_ipaddress>
3. Log on to the Move VM as the admin user.

login as: admin
4. Enter the password as nutanix/4u.
Note: As a security measure, first-time SSH logon into Move VM with user as admin and default password
nutanix/4u requires a password change.
admin@<<move_vm_ipaddress>'s password:
You will be logged on to the Move VM and the command prompt will change to admin@move on ~ $.
Resetting Admin Password

You can reset the password for the user admin. You need the password to log into the Move CLI.
About this task

To reset the admin password for Move VM, do the following:
Procedure
1. Open the VM console from Prism Web Console
2. Restart the Move VM
3. When the VM starts up, press any one of the arrow keys to view the entry as shown in the following image:
Figure 48: Boot Menu

4. Press Tab to edit the entry.
5. Append init=/bin/bash at the end of line as shown in the following image:
Figure 49: Command Append
6. Press Enter to start up the VM.

The VM starts up at the bash prompt.
7. Remount the root file system as read/write using the following command as shown in the image in Step 9:
mount -n -o remount,rw /
8. Change the password for the admin using the following command as shown in the image in Step 9:
passwd admin
9. Enter the New password and Retype new password.
Figure 50: New Password Reset
10. Restart the VM with the following command:

reboot -f
Resetting Web Login Password

You can reset your password if you have forgotten it.
About this task
Note: The password reset command is unavailable when invoked from a remote machine.
To reset the web logon password, do the following:
Procedure
1. SSH into the Move VM as an admin.
3. Go to the Move bin.

root@move on ~ $ cd /opt/xtract-vm/bin
4. List the files within the bin and open the CLI.
root@move on ~ $ cli-linux-amd64

5. In the CLI, run the password reset command.
localhost (Move) » password reset
Enter new password for 'Move' user nutanix(10):
Reenter password for 'Move' user nutanix(10):
Successfully reset the password [OK]
localhost (Move) »
Output displays a success message, Successfully reset the password [OK].
Changing Web Login Password

If you know your password and you want to change your password, you can use the following procedure.
About this task
Note: The password reset command is unavailable when invoked from a remote machine.
To change the web logon password, do the following:
Procedure
1. SSH into the Move VM as an admin.
3. Go to the Move bin.

root@move on ~ $ cd /opt/xtract-vm/bin
4. List the files within the bin and open the CLI.
root@move on ~ $ ./cli-linux-amd64
5. In the CLI, change the password.

localhost (Move) » password change
Enter password for 'Move' user nutanix(10):
Enter new password for 'Move' user nutanix(12):
Reenter password for 'Move' user nutanix(12):
Successfully changed the password [OK]
localhost (Move) »
Output displays a success message, Successfully changed the password [OK].
Error Adding Source

adding the source environment in the Move UI.
• Verify your vCenter Server credentials are correct.

• Verify vCenter Server name is DNS resolvable to IP address or IP address can be pinged from Move VM.
• If your ESXi hosts are registered in vCenter with hostnames instead of IP addresses, verify that the hostnames of
these ESXi hosts are resolvable from the Move VM.
• Verify service account used has admin privileges in vCenter.

Error Adding Target
adding the target environment in the Move UI.
Error Adding Target
• Verify that you are using AHV cluster IP address or FQDN.

• Verify that your AHV cluster credentials are correct.
• Verify that AHV cluster name is DNS resolvable to IP address or IP address can be pinged from Move VM.
• Verify service account used has admin privileges.
Missing Role Permission While Adding vCenter as a Provider

If you are facing missing role permission issue while adding vCenter as a provider, you can perform either
of the following workarounds to avoid the issue.
Workarounds
To update the permission in the Move VM and to successfully add vCenter as a provider, do either of the following.
• Assign the missing role or permission to the vCenter user.

For more information about assigning permissions, refer to Assigning Permission to vCenter User on page 31.
• Create the srcagent.json file with the following content in the /opt/xtract-vm/conf/ folder in the Move
VM, and restart the srcagent service from the Move CLI.
{"EsxProviderConfig": {
"RequiredESXiUserPrivileges": ["global.disablemethods", "global.enablemethods",
"global.licenses","sessions.terminatesession",
"sessions.validatesession","virtualmachine.config.addexistingdisk",
"virtualmachine.config.advancedconfig", "virtualmachine.config.annotation",
"virtualmachine.config.changetracking","virtualmachine.config.editdevice",
"virtualmachine.config.rawdevice", "virtualmachine.config.removedisk",
"virtualmachine.config.settings","virtualmachine.guestoperations.execute",
"virtualmachine.guestoperations.modify", "virtualmachine.guestoperations.query",
"virtualmachine.interact.poweroff", "virtualmachine.interact.poweron",
"virtualmachine.interact.deviceconnection", "virtualmachine.provisioning.diskrandomread",
"virtualmachine.state.createsnapshot", "virtualmachine.state.removesnapshot"]}}
Note: The preceding is a sample JSON file with default permissions used by Move. You can modify any
permission based on your requirement.
Manual Cleanup for VM Migrations

This section describes the steps one needs to perform for manual cleanup after VM migration actions such
as Cancel or Discard fail and the UI displays the migration status as Cleanup Failed.
A VM migration can have different types of providers as Source and/or Target. The message in the info icon besides
the Cleanup Failed error clearly states whether only the Source/Target cleanup has failed or if both have failed.
Move might have performed some of the cleanup steps during its failed attempt as part of the Discard or Cancel
action. Proceed with the next steps in case a step has already been performed.
Note: UVM refers to the VM being migrated.
The following sections list down the cleanup steps for different Source types and Target types:

AWS as a source
1. Remove the UVMs public IP from the security group of Move’s AWS agent.
2. Delete all the snapshots taken by Move for the volumes of the UVMs. Snapshots are named as Move-Snapxxxx.
Also search and delete the EBS volumes created from those snapshots by using snapshot-id.
3. Login to UVM and run following cleanup scripts for Linux and Windows respectively:
For Linux: /opt/Nutanix/CBTAPIProviderUninstall/scripts/cleanup_installation.sh
For Windows: C:\Nutanix\CBTAPIProviderUninstall\scripts\cleanup_installation.ps1
AHV as a source
Delete all the snapshots taken by Move for UVMs. Snapshots are named as Move-Snapxxxx.
Note: This can be done using Prism’s V3 APIs.
Hyper-V as a source
Delete all the checkpoints taken by Move for UVMs using the Hyper-V manager. The checkpoints are named as
Move-Snapxxxx.
ESXi as a source
1. Go to vCenter and delete all the snapshots taken by Move for the UVMs. Snapshots are named as Move-
Snapxxxx.
2. Go to vCenter and disable CBT for the UVMs in case it was originally disabled.
3. For ESXi UVM cleanup, download the following files from Move’s http server and run it in the UVM.
1. For Linux UVM, download cleanup_linux.sh
2. For Freebsd UVM, download cleanup_freebsd.sh
3. For Windows UVM, download cleanup.bat
For example, if MOVE_IP is Move’s IP, then download the following:
• For Linux: http://move_ip/resources/cleanup_linux.sh

• For Windows: http://move_ip/resources/cleanup.bat
• For Freebsd Distros: http://move_ip/resources/cleanup_freebsd.sh
AOS as a target
1. On the source UVMs, uninstall the Virtio driver if the target is AHV.

2. Delete the partially copied vdisks from the AOS containers which are mounted inside the Move appliance to free
up unwanted container space as shown in the following steps:
Note: If VM is successfully created on target (that is, VM migration is successful), Move automatically deletes
these files.
1. Perform a ‘ssh login’ to Move appliance and drop into root shell with the rs command.
2. If the target is AHV, then on the source UVM uninstall the Virtio driver.
3. Find the vdisks for the VM(s) for which the cleanup has failed.
1. Change directory using cd to /opt/xtract-vm/datamover
2. Run [find . -name "*vdiskname*" |xargs ls -ltr] for each vdisk and copy the full path and
then run the rm command on that path to delete the file.
Example: In the following example, we perform a find with VM name as the keyword and both the vdisk
for that VM came in the output since the vdisk name had the VM name in it.
The uuid in bold is the migration plan uuid. Before deleting this, we can match it in the Move UI with the
migration plan under which the VMs are present. On the Move UI, navigate inside the migration plan by
clicking on plan name and in the address bar. The last token is migration plan uuid (https://MOVE_IP/plan-
details/d43008ed-72d8-43c5-a404-4f93916ac538).
Note: find . -name "*RHEL-63-64bit*" |xargs ls -ltr

-rwxr-xr-x 1 diskwriter vmxtract 2147483648 May 15 2020 ./
CVM_10.136.74.14/1dd6f8b3-c4c6-42e7-928e-b5d2a6aa27f9/d43008ed-72d8-43c5-
a404-4f93916ac538/5554e915-16ca-5bcb-9a70-
b0cfc693d0b9/2001_RHEL-63-64bit_1.vmdk.raw
-rwxr-xr-x 1 diskwriter vmxtract 2147483648 May 15 2020 ./
CVM_10.136.74.14/1dd6f8b3-c4c6-42e7-928e-b5d2a6aa27f9/d43008ed-72d8-43c5-
a404-4f93916ac538/0a6d5b57-074d-5ba1-8c25-9a749a969c6c/2000_RHEL-63-32bit_1.vmdk.raw
3. Once the files are deleted, run the Curator full scan to reclaim the free space.
AWS as a target
1. Login to AWS EC2 console.
2. Find and delete the Move agent with the name <vmname>-NTNX-MOVE-AGENT where the vmname is the name
of the UVM.
For example if the VM name is Solaris-prod then the Move agent name would be Solaris-prod-NTNX-MOVE-
AGENT.
Changing Default TCP to KCP Protocol of Move

This section covers when and how to change the underlying transport protocol of Move from the default
Transmission Control Protocol (TCP) to KCP (a reliable User Datagram Protocol (UDP) based protocol).
You can change the protocol for better performance if the migration is performed on an unreliable network
(packet loss) for AWS migrations.
Note: This procedure is only applicable for AOS to AWS migrations.
Choosing KCP over TCP

KCP is designed to outperform TCP in the lossy networks and provide better migration throughput.

Checking for a Non-Reliable Network Suited for KCP
Let us assume, you are doing a migration from AOS to AWS, and the Move-Agent (NTNX-MOVE-AGENT) is
deployed on the EC2 region selected for migration. You want to check if the connection is reliable and suitable for
TCP between the Move-Agent and the on-prem Move appliance (Nutanix-Move).
You can perform the following checks from Nutanix-Move to NTNX-MOVE-AGENT to determine the packet-loss
ratio.
Note: You can do ping tests to determine packet loss and RTT between two endpoints.
--- 52.53.203.101 ping statistics ---
1000 packets transmitted, 995 received, 0% packet loss, time 901325ms
rtt min/avg/max/mdev = 308.469/309.267/567.929/11.093 ms
Packet loss percentage = ((packets transmitted - packets received)/packets transmitted) * 100 For example,
5/1000 * 100 = 0.5%
Run the test multiple times to get the average results over a period. If the preceding ping test results in an average
packet loss ratio higher than 0.2%, it is recommended to switch the transport protocol from the default TCP to KCP.
Table 26: Performance Matrix of KCP over TCP
Network packet loss Time taken for 30G data transfer (in minutes) Performance of KCP
over TCP
KCP TCP
0.1% 33 58 76%
0.5% 99 262 165%
2.0% 120 700 483%
Changing the Protocol from TCP to KCP

To use KCP, change the configuration files of the disk reader and the disk writer.
For AOS to AWS migrations, change the disk reader configuration on Nutanix-Move and the disk writer
configuration on the NTNX-MOVE-AGENT.
Disk reader configuration file: /opt/xtract-vm/conf/diskreader.json
Disk writer configuration file: /opt/xtract-vm/conf/diskwriter.json
Following is the JSON configuration for changing the protocol.
{
"Transport": {
"Protocol": "KCP"
}
}
Once you change the configurations, restart the services on both Nutanix-Move and NTNX-MOVE-AGENT using
svcrestart. The protocol will be now changed to KCP.
Testing Network Performance of Move

If you are facing any performance issues such as slow migration, you can run Iperf to troubleshoot network
related issues.

Running Iperf as a Server within Nutanix-Move VM
To run Iperf as a server, do the following:
1. Expose the port from /opt/xtract-vm/bin/docker-compose.yml
2. In the docker-compose.yml file, in the diskwriter section, map the ports for connection.
3. Run the container shell.
For example, diskwriter-shell
4. Switch to the root user of the Move VM and run the following command in the shell.
> iperf3 s -p <-port>
Running Iperf as a Client within Nutanix-Move VM

To run Iperf as a client, do the following:
1. Run the container shell.
For example, diskwriter-shell
2. Switch to the root user of the Move VM and run the following command in the shell.
> iperf3 c <-server ip> p <-port>
Improving Migration Performance

If you are facing slow migration of VMs, you can upgrade RAM of Move VM from 4 GB to 8 GB based on
your requirement. You can also change the configuration for each host stream or diskreader.
Move scheduler has a few limits which controls how many disks across different VMs from different ESXi hosts can
be copied in parallel at any given time.
PerHostLimit: 8
PerHostLimit defines the maximum number of disks copied in parallel from one ESXi host. For each disk, Move
deploys multiple streams for faster copying of data. The number of streams vary from 1 to 4. Move dynamically
increases or decreases the number of streams depending on the load on the ESXi host.
CAUTION: It is strongly advisable not to manually modify either PerHostLimit or the number of streams, or
else the performance may deteriorate due to read errors from ESXi host.
So, Move can copy maximum 8 disks actively at any point from a single ESXi host. When you have VMs from more
than one ESXi host, then PerReaderLimit is configured.
PerReaderLimit : 16
PerReaderLimit defines the maximum copy tasks at any time across all ESXi hosts. The default value of 16 suffices
two ESXi hosts as PerHostLimit value is 8.
If you have more than 2 ESXi hosts, then you can manually modify this limit by changing the following configutaion
in /opt/xtract-vm/conf/srcagent.json file. If file is not present, you can create the srcagent.json file . In
the following example, the value 32 will be sufficient for 4 hosts (4 * 8).
{
"SchedulerConfig": {
"PerReaderLimit": 32
}
}
After making the configuration changes, restart the Move services by running the svcrestart command.

With one host, Move at max consumes around 600 MB of RAM. The default RAM of Move VM is 4 GB and that
should suffice 4 ESXi hosts (Move does not create new copy streams if memory used is beyond 60%). So, if you have
more than 4 ESXi hosts, then increase RAM of Move VM.
Debugging Stats
This section guides you through the steps for debugging the stats.
Move is composed of multiple internal services for reading, writing data, and coordination. Each service exposes stats
through REST/HTTP to localhost. Stats are also available in the support bundle for offline analysis.
#Query stats from disk reader,[admin@Nutanix-Move ~]$ curl localhost:8099/debug/vars
# disk writer, [admin@Nutanix-Move ~]$ curl localhost:2000/debug/vars
# source agent [admin@Nutanix-Move ~]$ curl localhost:8085/debug/vars
#and target agent [admin@Nutanix-Move ~]$ curl localhost:8086/debug/vars
Xtract Lite Deployment

Move deploys the T2.Medium instance type on AWS as a Xtract Lite instance. The instance type can be
changed only after the deployment. For some users, the move agent deployment fails because default
move agent type, T2.Medium instance type, is not supported in selected regions.
Note:
This section is not applicable for AWS to AHV and AWS to ESXi on Nutanix from Move 3.7.0 onwards.
To have a customised instance type, the Move agent needs srcagent.json file to be created in the /opt/xtract-
vm/conf location in the srcagent-shell shell. Do the following to create srcagent.json if not present already:
• Run srcagent-shell
• Run vi srcagent.json
• Specify the instance type in this format:
{
"AwsProviderConfig": {
"AgentInstanceType": "t2.small"
}
}
• Run docker restart bin_srcagent_1

For more information, see KB-9460.
Troubleshooting UI Issues
This section guides you through the troubleshooting steps for some of the issues you might encounter in
the Move UI.
• Source vCenter VM list is empty when selecting VMs for migration.

Troubleshooting step: Ensure to wait for a few minutes for Move VM to build inventory database and click the
Refresh link.
• If you refresh (F5) is the browser, and if the GUI loads with no data.
Troubleshooting step: In the web browser, type https://ip-address and logon again.

• When UI shows an error message without any details.
Troubleshooting step: Download the Support Bundle logs containing extra error information.
Missing Static IP Address Post Migration

If the static IP address is not assigned or the static IP address is lost after migration, you can check the
logs.
After the VM migration, previous assigned static IP addresses are lost. In Windows, you can collect the log files at C:
\Nutanix\Temp. In Linux, you can collect the log files at /tmp/xtract-guest.log.
Contact Nutanix Support at https://portal.nutanix.com/ and send the log files.
Bringing Disks Online Post Migration (Windows)

You can bring the Windows disks online after they are converted to the AHV format. When the VM disks
are converted to the AHV format, they appear as new disks. Move brings the disks online automatically.
However, if you chose to bypass the guest operations, then perform the following tasks to bring the disks
online after migration.
About this task

To bring the Windows disks online after migration, do the following:
Procedure
1. Log on to the Windows guest operating system in the VM.
2. Open a command window or PowerShell console, and then log on as an admin.
3. Change the SAN policy to bring all the disks online.

>> echo san policy=OnlineAll | diskpart
All the Windows disks become online.

COPYRIGHT
Copyright 2021 Nutanix, Inc.
Nutanix, Inc.
1740 Technology Drive, Suite 150
San Jose, CA 95110
All rights reserved. This product is protected by U.S. and international copyright and intellectual property
laws. Nutanix and the Nutanix logo are registered trademarks of Nutanix, Inc. in the United States and/or other
jurisdictions. All other brand and product names mentioned herein are for identification purposes only and may be
trademarks of their respective holders.
Move | Copyright | 155

Nutanix Move v3 - 7

Uploaded by

Copyright:

Available Formats

Nutanix Move v3 - 7

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nutanix Move v3 - 7

Uploaded by

Copyright:

Available Formats

Move 3.

Move User Guide

Move Migration Workflow...............................................................................26

ESXi to AHV and ESXi to Nutanix Clusters on AWS VM Migration............ 27

ESXi to ESXi VM Migration............................................................................ 51

Hyper-V to AHV and Hyper-V to Nutanix Clusters on AWS VM Migration.. 72

AWS to AHV and AWS to Nutanix Clusters on AWS VM Migration............ 90

AWS to ESXi VM Migration.......................................................................... 105

AHV to AWS VM Migration...........................................................................118

Environments and Migration Plan Management........................................ 131

Move Administration..................................................................................... 134

Move Troubleshooting.................................................................................. 143

• VMware ESXi to Nutanix clusters on AWS and AHV

Note: As a part of this workflow, a service disruption is expected during cutover.

Figure 1: Distributed Architecture of Move

Move | Move Overview | 6

• VMware ESXi to Nutanix AHV

Note: Nutanix converts the source VM disks to AHV format.

Note: No other copies of the data are stored by Move.

• Nutanix AHV to AWS EC2

• Migrate powered on or powered off VMs.

Move | Move Overview | 7

Move Software Package

Note: version-number in the utility name is the version number of Move.

Table 1: Move ZIP file for AHV: move-<version-number>.zip

Utility name Description

Deployer utility for the following operating systems:

move-version-number.qcow2 Base disk image

Table 2: Move Offline Upgrade Package: move-offline-upgrade-<version-number>.zip

Utility Name Description

Deployer utility for the following operating systems:

Move | Move Overview | 8

Table 3: Move OVA file for ESXi: mmove-<version-number>-esxi.ova

Utility Name Description

Supported AOS, ESXi, and Hyper-V Version

Firewall Port Requirements

Figure 2: Firewall Port Diagram

Source Destination Port number Protocol

Nutanix-Move DNS Server 53 UDP

Move | Move Overview | 9

Ports for All Source-Target Combinations

Table 5: User Workstation to Nutanix-Move

Source User Workstation

Ports for ESXi to AHV Migration

Table 6: Nutanix-Move to Prism (AHV Cluster)

Ports for ESXi to ESXi Migration

Table 7: Nutanix-Move to ESXi Source

Table 8: Nutanix-Move to vCenter

Move | Move Overview | 10

Table 9: Nutanix-Move to Prism (AOS Cluster)

Ports for Hyper-V to AHV Migration

Table 10: Nutanix-Move to Hyper-V Host

Table 11: Nutanix-Move to Hyper-V Guest VM

Table 12: Nutanix-Move to Prism (AHV Cluster)

Move | Move Overview | 11

Ports for AWS to AHV and ESXi (AOS) Migration

Table 13: Nutanix-Move to AWS

Source Nutanix Move

Ports for AHV to AWS Migration