Nutanix Move: ESXi 호스트 연결 오류와 DNS 점검

MaruOps

2026.10.26

참고 사진 · 두 네트워크 스위치의 포트에 연결된 이더넷 케이블 · 사진: Jon 'ShakataGaNai' Davis / 원본 / CC BY-SA 3.0 · 목록용 크기 조정

Nutanix Move에서 마이그레이션할 VM을 선택하려는데 Non-Migratable로 표시되고, 사유에 “The host for this VM is not reachable”가 나타날 수 있습니다. 이때 vCenter에 접속된다는 이유만으로 모든 ESXi 호스트까지 통신된다고 판단하면 원인을 놓치기 쉬워요.

이 글은 Nutanix KB-7519를 바탕으로, Move 컨테이너의 ESXi 이름 해석 실패를 확인하는 순서를 정리합니다. DNS 설정을 바로잡는 방법을 먼저 살펴보고, DNS에 레코드를 추가할 수 없을 때의 extra_hosts 대안과 재시작 전후 확인까지 다룹니다.

이 글의 목차

이 KB를 적용할 수 있는 증상

같은 화면 메시지라도 원인은 다를 수 있습니다. 먼저 /opt/xtract-vm/logs/srcagent.log에서 실패한 ESXi 이름과 오류 종류를 확인합니다. 다음은 KB의 오류 형태를 예시 도메인으로 바꾼 것으로, 이 글에서 수집한 실측 로그는 아닙니다.

lookup esxi01.example.com on 127.0.0.11:53: no such host

lookup과 no such host는 TCP 연결 전에 이름을 찾는 단계에서 실패했다는 단서입니다. 반대로 IP가 확인된 뒤 연결 시간이 초과되거나 인증서 오류가 발생했다면 그 단계의 문제를 따로 조사해야 합니다. extra_hosts를 모든 접속 오류의 해결책으로 사용하지 않습니다.

확인 결과	다음에 살펴볼 대상
ESXi 이름을 IP로 찾지 못함	Move가 사용하는 DNS와 ESXi 레코드
이름은 올바른 IP로 바뀌지만 TCP 연결 실패	라우팅·방화벽·대상 포트
Move 호스트 셸만 이름 해석 성공	실제 서비스 컨테이너의 이름 해석
일부 VM만 실패	해당 VM이 올라간 ESXi의 FQDN과 관리 IP

KB의 영향 범위 표기는 모든 Nutanix MoveVM 버전이며, 원문 수정일은 2026년 1월 23일입니다. 이 글의 확인일은 2026년 10월 26일입니다. 실제 서비스 이름과 명령 제공 여부는 설치한 Move 버전 및 원문과 대조합니다.

Move 호스트와 컨테이너를 구분하기

Move 어플라이언스에 SSH로 들어가서 실행하는 명령과, 그 안의 srcagent 컨테이너에서 실행하는 명령은 서로 다른 환경을 봅니다. 호스트에서 ping이나 이름 조회가 성공했다고 해서 서비스 컨테이너도 같은 결과를 얻는 것은 아닙니다.

Docker의 사용자 정의 네트워크에서는 127.0.0.11이 내장 DNS 주소로 사용됩니다. 따라서 위 로그의 주소가 보인다는 이유만으로 DNS 서버를 잘못 지정했다고 단정할 수는 없습니다. 확인할 것은 컨테이너가 조회하는 ESXi 이름과 그 이름에 대한 응답입니다. Docker DNS 동작에 이 구조가 설명되어 있습니다.

호스트의 /etc/hosts에 추가한 사용자 정의 항목은 컨테이너에 자동 상속되지 않습니다. 이 때문에 Move 호스트의 파일만 수정한 뒤 문제가 그대로 남을 수 있어요. Linux 컨테이너에 정적 이름 매핑을 넣을 때 사용하는 Compose 항목이 extra_hosts입니다.

변경 전에 컨테이너에서 확인할 항목

아래 작업은 Move 어플라이언스에서 수행합니다. AHV 호스트나 CVM에서 실행하는 절차가 아닙니다. 예시의 esxi01.example.com, 192.0.2.11, 192.0.2.20은 문서용 값이므로 실제 ESXi FQDN·관리 IP·vCenter IP로 바꿉니다.

SSH로 Move의 admin 계정에 접속한 다음, KB에서 안내하는 명령으로 root 셸과 소스 에이전트 셸에 차례로 들어갑니다. rs에서 요청하는 값은 Move admin의 암호입니다.

rs
srcagent-shell

이제 srcagent 컨테이너 안에서 실행합니다. getent가 제공되는 환경에서는 이름 조회 결과를 먼저 확인하고, 이어서 포트를 확인합니다.

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 443

nc는 한 줄씩 실행합니다. 연결 성공 후 입력을 기다리면 Ctrl+C로 해당 검사를 끝내고 다음 줄을 실행합니다. -w 5는 연결 시도 제한 시간이며, 성공한 세션을 무조건 5초 후 닫는 옵션은 아닙니다. 옵션 의미는 Ncat 매뉴얼에서 확인할 수 있습니다.

출발 위치	목적지	이 문제에서 확인할 TCP 포트
Move 서비스 컨테이너	원본 ESXi 호스트 각각	443, 902
Move 서비스 컨테이너	vCenter	443

이 표는 원본 VMware 환경의 해당 접속을 확인하기 위한 목록입니다. 전체 마이그레이션에 필요한 모든 포트를 나열한 표는 아닙니다. 같은 연결 조건은 AWS의 Nutanix Move 구현 안내에서도 확인할 수 있습니다.

한 ESXi만 검사하고 끝내지 말고, 인벤토리에 등록된 이름을 기준으로 모든 원본 호스트를 대조합니다. DNS가 잘못된 다른 IP를 반환하는 경우도 있으므로 응답이 있다는 사실과 응답 주소가 맞다는 사실을 구분합니다. 점검이 끝나면 exit로 컨테이너 셸을 빠져나옵니다.

exit

DNS 서버 주소와 레코드 중 무엇을 고칠까

Move에 설정한 DNS 서버 주소가 잘못된 경우

KB는 Move의 root 셸에서 configure-static-ip를 실행해 잘못된 DNS 설정을 수정하도록 안내합니다. 이 명령은 Move 서비스를 재시작하므로 진행 중인 마이그레이션에 영향을 줍니다. 실행 전에 작업 상태와 유지보수 시간을 확인하고 현재 IP·넷마스크·게이트웨이·DNS 설정을 기록합니다.

configure-static-ip

네트워크 설정을 다루는 대화형 명령입니다. DNS를 고치려는 상황에서 관리 IP나 게이트웨이까지 임의로 바꾸지 않습니다. 완료 후 Move UI에 다시 접속하고, 컨테이너에서 같은 ESXi FQDN을 다시 확인합니다.

DNS 서버는 맞지만 ESXi 레코드가 없는 경우

가능하면 조직의 DNS에 필요한 ESXi 이름과 관리 IP를 등록하는 방식으로 해결합니다. KB는 이 경로에서는 별도의 Move 서비스 재시작 없이 동적 이름 해석으로 반영될 수 있다고 안내합니다. 실제 응답을 확인한 뒤 소스 인벤토리를 새로 고칩니다.

이름과 주소의 대응을 DNS에서 관리하면 ESXi가 추가되거나 IP가 바뀔 때 여러 컨테이너의 정적 목록을 따로 고칠 필요가 줄어듭니다. DNS 운영 정책상 등록할 수 없는 경우에만 다음 정적 매핑 경로를 검토합니다.

DNS 등록이 어려울 때 extra_hosts 적용

이 절차는 KB가 안내하는 어플라이언스 내부 구성 변경입니다. 서비스 재시작에 따른 진행 중인 이관 작업의 영향을 먼저 확인합니다. 파일 경로나 서비스 이름이 원문과 다르면 해당 버전의 절차를 확인한 뒤 진행합니다.

원본 파일 보관

Move root 셸에서 시간별 백업 디렉터리를 만들고 두 파일을 보관합니다. 출력된 경로를 작업 기록에 남겨 두세요.

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"

호스트의 기존 /etc/hosts 항목을 보존하면서 실제 주소를 추가합니다. 아래는 추가할 줄의 예시이며 파일 전체 내용이 아닙니다.

192.0.2.11 esxi01.example.com
192.0.2.12 esxi02.example.com

실제 서비스에 동일한 매핑 추가

다음 파일을 편집합니다.

vi /opt/xtract-vm/bin/docker-compose.yml

아래 YAML은 삽입 위치를 보여 주는 발췌 예시입니다. 실제 파일을 이 내용으로 통째로 교체하지 않습니다. 기존 image, environment, volumes 등은 유지하고 extra_hosts를 environment와 같은 단계에 넣습니다. 들여쓰기에는 공백을 사용합니다.

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는 DNS 서버에 레코드를 만드는 기능이 아니라 해당 컨테이너의 이름 매핑을 제공하는 기능입니다. 원본 ESXi가 더 많으면 필요한 이름을 빠짐없이 추가합니다.

실제 구성의 서비스	적용 판단
`srcagent`	소스 이름 매핑 추가
`diskreader`	소스 이름 매핑 추가
`diskreader_vddkXXX` 계열	실제 파일에 있는 해당 서비스에도 동일하게 추가
`tgtagent`, `diskwriter`	대상도 ESXi일 때 대상 이름 매핑 추가; AHV 대상이면 이 단계 생략

diskreader_vddkXXX는 그대로 만들 서비스 이름이 아닙니다. KB는 버전 조합에 따라 diskreader_vddk601, diskreader_vddk7 같은 서비스가 사용될 수 있다고 설명합니다. 파일에 존재하는 서비스 이름을 확인하고, 일반 diskreader만 수정한 채 다른 읽기 서비스를 빠뜨리지 않습니다.

서비스 재시작과 복귀

파일의 호스트 이름·주소·들여쓰기를 검토한 뒤 Move root 셸에서 KB의 명령을 실행합니다.

svcrestart

서비스 재시작은 진행 중인 VM 이관에 영향을 줄 수 있으며, 관련 계획의 취소와 재시작이 필요할 수 있습니다. 작업 상태를 확인한 뒤 유지보수 순서에 맞춰 실행합니다. 서비스가 돌아오면 UI를 새로 고치고 소스 인벤토리를 갱신합니다.

해결 여부와 되돌리기 기준

성공 여부는 호스트 셸의 이름 조회 한 번으로 판단하지 않습니다. 다음을 같은 작업 기록에 남깁니다.

srcagent에서 ESXi 이름이 예상 관리 IP로 해석되는지
관련 컨테이너의 정적 매핑에 원본 ESXi가 빠지지 않았는지
ESXi 443·902와 vCenter 443의 TCP 연결이 되는지
소스 인벤토리에서 VM을 선택할 수 있고, 같은 이름 조회 오류가 새로 발생하지 않는지

변경 직후 서비스가 시작되지 않거나 매핑 오류가 확인되면 저장한 원본으로 되돌릴 수 있습니다. 아래 YYYYMMDD-HHMMSS는 앞에서 기록한 실제 백업 디렉터리로 바꿉니다. 다른 관리자의 후속 수정이 없는지도 먼저 확인합니다. 되돌린 뒤의 svcrestart 역시 유지보수 작업입니다.

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
svcrestart

이 방법은 정적 매핑 변경을 되돌리는 절차입니다. configure-static-ip로 바꾼 네트워크 설정을 복원하는 명령은 아닙니다. 정적 목록을 사용하는 동안에는 ESXi 추가·IP 변경·Move 업그레이드 후에도 실제 매핑과 적용 상태를 다시 확인합니다.

이름과 포트를 모두 확인했는데 같은 증상이 계속되면 Move 버전, 실패 VM과 ESXi FQDN, 컨테이너별 확인 결과, 오류 발생 시각과 관련 로그를 모아 Nutanix Support에 전달합니다. 로그에 포함된 자격 증명이나 비밀 값은 공개 글에 올리지 않습니다.

출처와 확인 범위

원문의 절차와 버전 표기는 Nutanix KB-7519를 기준으로 확인했습니다. Docker의 호스트 파일 상속 범위와 Compose extra_hosts 사양을 함께 대조했습니다.

이 글의 YAML 매핑과 일반 Docker 컨테이너의 호스트 파일 분리는 격리된 실습에서 확인했습니다. 실제 Move 어플라이언스에서 장애를 재현하거나 configure-static-ip, svcrestart, VM 이관을 실행한 검증은 아닙니다. 위 진단 순서는 KB에 운영 전후의 확인과 되돌리기 기준을 덧붙여 정리한 것입니다.

대표 이미지는 일반 네트워크 장비 참고 사진이며 이 글의 Move·ESXi 환경을 촬영한 사진이 아닙니다. 사진: Jon ‘ShakataGaNai’ Davis · 원본 · CC BY-SA 3.0. 기존 서버 저장 사진을 재사용하며, 원래 비율을 유지하고 목록용 썸네일은 잘라 표시할 수 있습니다.