In Nutanix Move, a VM may appear as Non-Migratable with the reason “The host for this VM is not reachable.” A working vCenter connection does not establish that Move can also reach every ESXi host.
This guide uses Nutanix KB-7519 to organize checks for ESXi name resolution failures inside Move containers. It covers correcting DNS configuration, using extra_hosts when DNS records cannot be added, and checking the result before and after a service restart.
On this page
Check whether this KB matches the failure
The same UI message can have different causes. Start with the failing ESXi name and error type in /opt/xtract-vm/logs/srcagent.log. The following illustrates the KB’s error pattern with a documentation domain; it is not a log collected in this article’s test environment.
lookup esxi01.example.com on 127.0.0.11:53: no such hostlookup and no such host point to a name resolution failure before the TCP connection. A timeout after an address is resolved, or a certificate error, requires investigation at that stage instead. extra_hosts is not a general remedy for all connection failures.
| Observation | Investigate next |
|---|---|
| ESXi name does not resolve | DNS used by Move and the ESXi record |
| Name resolves correctly but TCP fails | Routing, firewall, and destination port |
| Only the Move host shell resolves the name | Resolution inside the service container |
| Only some VMs fail | FQDN and management IP of their ESXi hosts |
The KB lists all Nutanix MoveVM versions as affected and was last modified on January 23, 2026. This guide was checked on October 26, 2026. Compare service names and available commands with your installed Move version and the source article.
Separate the Move host from its containers
Commands run over SSH on the Move appliance and commands inside its srcagent container inspect different environments. Successful ping or name resolution in the host shell does not establish that the service container gets the same result.
On a Docker custom network, 127.0.0.11 is the embedded DNS address. Seeing that address in a log therefore does not by itself establish a misconfigured DNS server. Check the ESXi name being queried and the response available to the container. See Docker DNS behavior.
Custom entries in the host’s /etc/hosts are not inherited automatically by containers. Editing only the Move host’s file can therefore leave the failure unchanged. Compose’s extra_hosts setting supplies static host mappings to a Linux container.
Check from the container before making changes
Perform these steps on the Move appliance, not an AHV host or CVM. Replace esxi01.example.com, 192.0.2.11, and 192.0.2.20 with the real ESXi FQDN, management IP, and vCenter IP. These are documentation values.
Connect over SSH as Move’s admin user, then use the KB’s commands to enter the root shell and source agent shell in that order. The password requested by rs is the Move admin password.
rs
srcagent-shellRun the following inside the srcagent container. Where getent is available, inspect the name lookup result before checking the ports.
getent hosts esxi01.example.com
cat /etc/resolv.conf
nc -v -w 5 esxi01.example.com 443
nc -v -w 5 esxi01.example.com 902
nc -v -w 5 192.0.2.20 443Run each nc command separately. If a successful connection waits for input, press Ctrl+C to finish that check before continuing. -w 5 limits the connection attempt; it does not necessarily close an established session after five seconds. See the Ncat manual.
| Starting point | Destination | TCP ports relevant to this check |
|---|---|---|
| Move service container | Each source ESXi host | 443, 902 |
| Move service container | vCenter | 443 |
This table covers these source VMware connections, not every port needed for a complete migration. AWS’s Nutanix Move implementation guidance documents the same source connections.
Check every source host using the names registered in the inventory. Do not stop after one successful ESXi test. A DNS response can also contain the wrong address, so verify both that resolution succeeds and that its result is correct. When finished, leave the container shell with exit.
exitDecide whether to fix the DNS server or its records
Move has the wrong DNS server configuration
The KB directs administrators to run configure-static-ip in the Move root shell to correct the DNS configuration. This command restarts Move services and affects ongoing migrations. Review task status and the maintenance window first, and record the current IP, netmask, gateway, and DNS settings.
configure-static-ipThis is an interactive network configuration command. Do not change the management IP or gateway incidentally while correcting DNS. Afterward, reconnect to the Move UI and check the same ESXi FQDN from the container again.
DNS servers are correct but ESXi records are missing
Where possible, register the required ESXi names and management IPs in your organization’s DNS. The KB explains that dynamic resolution can pick up this correction without a separate Move service restart. Verify the actual response before refreshing the source inventory.
Managing the mapping in DNS reduces the need to update static lists in multiple containers when hosts are added or addresses change. Consider the static mapping path below when organizational DNS records cannot be added.
Apply extra_hosts when DNS records cannot be added
This changes internal appliance configuration as described by the KB. First review the effect of service restarts on active migrations. If the file path or service names differ, establish the procedure for your installed version before proceeding.
Preserve the original files
In the Move root shell, create a timestamped backup directory and preserve both files. Record the printed directory path.
kb7519_backup="/root/move-kb7519-$(date +%Y%m%d-%H%M%S)"
mkdir -m 700 "$kb7519_backup"
cp -a /etc/hosts "$kb7519_backup/hosts"
cp -a /opt/xtract-vm/bin/docker-compose.yml "$kb7519_backup/docker-compose.yml"
printf '%s\n' "$kb7519_backup"Add the actual mappings to the host’s /etc/hosts while preserving its existing entries. These are example additions, not the complete file.
192.0.2.11 esxi01.example.com
192.0.2.12 esxi02.example.comAdd the same mappings to the relevant services
Edit this file:
vi /opt/xtract-vm/bin/docker-compose.ymlThe YAML below is an excerpt showing insertion points. Do not replace the entire existing file with it. Retain image, environment, volumes, and other settings, and put extra_hosts at the same indentation level as environment. Use spaces for indentation.
services:
srcagent:
extra_hosts:
- "esxi01.example.com:192.0.2.11"
- "esxi02.example.com:192.0.2.12"
diskreader:
extra_hosts:
- "esxi01.example.com:192.0.2.11"
- "esxi02.example.com:192.0.2.12"extra_hosts supplies container host mappings; it does not create DNS server records. Include all required source ESXi names.
| Service in the actual configuration | Where mappings apply |
|---|---|
srcagent | Add source mappings |
diskreader | Add source mappings |
diskreader_vddkXXX variants | Add the same mappings to the relevant existing services |
tgtagent, diskwriter | Add destination mappings when the target is also ESXi; skip for an AHV target |
diskreader_vddkXXX is not a literal service name to create. The KB identifies examples such as diskreader_vddk601 and diskreader_vddk7, depending on the version combination. Inspect the names in the actual file rather than updating only the generic diskreader and overlooking another reader service.
Restart services and return to the UI
Review hostnames, addresses, and indentation, then run the KB’s command in the Move root shell.
svcrestartA service restart can affect ongoing VM migrations and may require canceling and restarting the related migration plan. Review task state and execute it as part of the maintenance procedure. When services return, reload the UI and refresh the source inventory.
Verify the result and define rollback
A successful lookup in the host shell alone is insufficient. Record these checks together:
- Whether
srcagentresolves ESXi names to the expected management IPs - Whether static mappings in the relevant containers include every required source host
- Whether ESXi TCP 443 and 902 and vCenter TCP 443 are reachable
- Whether the source inventory allows VM selection and no new instance of the same lookup error appears
If services fail to start immediately after the change or mappings are incorrect, restore the saved originals. Replace YYYYMMDD-HHMMSS below with the actual recorded backup directory. Check for subsequent edits by another administrator first. The rollback’s svcrestart is also a maintenance operation.
kb7519_backup=/root/move-kb7519-YYYYMMDD-HHMMSS
cp -a "$kb7519_backup/hosts" /etc/hosts
cp -a "$kb7519_backup/docker-compose.yml" /opt/xtract-vm/bin/docker-compose.yml
svcrestartThis rolls back the static mapping changes. It does not restore network settings changed through configure-static-ip. While static lists remain in use, recheck mappings and their application after ESXi additions, IP changes, and Move upgrades.
If the same symptom persists after names and ports are verified, collect the Move version, affected VMs and ESXi FQDNs, per-container results, error timestamps, and relevant logs for Nutanix Support. Do not publish credentials or secrets contained in those logs.
Sources and verification scope
The procedure and affected-version statement were checked against Nutanix KB-7519. Docker’s host file inheritance behavior and Compose extra_hosts specification provide the container background.
The YAML mappings and separation of host files in ordinary Docker containers were checked in an isolated lab. This was not a reproduction on a Move appliance, and it did not execute configure-static-ip, svcrestart, or a VM migration. The diagnostic sequence adds operational verification and rollback criteria to the KB’s procedure.
The cover is a general network equipment photograph, not the Move or ESXi environment discussed here. Photo: Jon ‘ShakataGaNai’ Davis · original · CC BY-SA 3.0. The existing locally hosted photo is reused; its aspect ratio is retained, and listing thumbnails may be cropped.
