NSX Cloud FAQ 및 문제 해결

이 항목에서는 자주 묻는 몇 가지 질문과 문제 해결 정보를 다룹니다.

NSX Tools를 설치한 후 nsxcli 명령에 액세스하려면 어떻게 합니까?

Linux VM에 NSX Tools를 설치한 후 다음을 수행합니다.

NSX Tools를 설치한 Linux VM에 로그인합니다.
sudo service nsx-agent-chroot nsx-exec bash 명령을 실행합니다. bash 셸로 이동됩니다.
이제 nsxcli 명령을 실행합니다. nsxcli 프롬프트로 이동됩니다.

이제 get firewall rules 등과 같은 필수 nsxcli 명령을 실행할 수 있습니다.

Windows VM에 NSX Tools를 설치한 후 다음을 수행합니다.

NSX Tools를 설치한 Windows VM에 로그인합니다.
PowerShell을 엽니다.
PowerShell 프롬프트에서 nsxcli 명령을 실행합니다. nsxcli 프롬프트로 이동됩니다.

이제 get firewall rules 등과 같은 필수 nsxcli 명령을 실행할 수 있습니다.

NSX Cloud 구성 요소가 설치되어 실행 중인지 확인하려면 어떻게 합니까?

워크로드 VM의 NSX Tools가 PCG에 연결되어 있는지 확인하려면 다음을 수행합니다.
1. nsxcli 명령을 입력하여 NSX CLI를 엽니다.
2. 다음 명령을 입력하여 게이트웨이 연결 상태를 가져옵니다. 예를 들면 다음과 같습니다.
```
get gateway connection status
Public Cloud Gateway  : nsx-gw.vmware.com:5555
Connection Status 	: ESTABLISHED 
```
워크로드 VM에 올바른 태그가 있어야 PCG에 연결할 수 있습니다.
1. AWS 콘솔 또는 Microsoft Azure 포털에 로그인합니다.
2. VM의 eth0 또는 인터페이스 태그를 확인합니다.
  nsx.network 키의 값은 default여야 합니다.

cloud-init를 사용하여 시작된 내 VM이 격리되고 타사 도구의 설치를 허용하지 않습니다. 어떻게 해야 합니까?

격리 정책을 사용하도록 설정하면 다음 규격의 cloud-init 스크립트를 사용하여 VM을 시작할 때 VM이 격리되고 사용자 지정 애플리케이션 또는 도구를 설치할 수 없습니다.

nsx.network=default 태그 지정
VM의 전원을 켤 때 자동으로 설치되거나 부트스트랩된 사용자 지정 서비스

해결 방법:

default(AWS) 또는 default-vnet-<vnet-ID>-sg(Microsoft Azure) 보안 그룹을 업데이트하여 사용자 지정 또는 타사 애플리케이션을 설치하는 데 필요한 인바운드/아웃바운드 포트를 추가합니다.

VM에 태그를 올바르게 지정하고 NSX Tools를 설치했지만 VM이 격리되었습니다. 어떻게 해야 합니까?

이 문제가 발생하면 다음을 시도해 보십시오.

NSX Cloud 태그 nsx.network 및 해당 값 default를 올바로 입력했는지 확인합니다. 이것은 대/소문자를 구분합니다.
CSM에서 AWS 또는 Microsoft Azure 계정을 다시 동기화합니다.
- CSM에 로그인합니다.
- 클라우드 > AWS/Azure > 계정으로 이동합니다.
- 공용 클라우드 계정 타일에서 작업을 클릭하고 계정 다시 동기화를 클릭합니다.

워크로드 VM에 액세스할 수 없는 경우 어떻게 해야 합니까?

공용 클라우드에서(AWS 또는 Microsoft Azure)

NSX Cloud에서 관리되는 포트를 포함한 VM의 모든 포트, OS 방화벽(Microsoft Windows 또는 IPTables) 및 NSX-T Data Center가 트래픽을 허용하도록 올바로 구성되었는지 확인합니다.

예를 들어 VM에 대한 ping을 허용하려면 다음을 올바로 구성해야 합니다.
- AWS 또는 Microsoft Azure의 보안 그룹. 자세한 내용은 NSX Cloud 격리 정책을 사용한 위협 감지 항목을 참조하십시오.
- NSX-T Data Center DFW 규칙. 자세한 내용은 NSX 적용 모드의 NSX 관리 워크로드 VM에 대한 기본 연결 전략 항목을 참조하십시오.
- Windows Firewall 또는 Linux의 IPTables
SSH 또는 다른 방법(예: Microsoft Azure의 직렬 콘솔)을 사용하여 VM에 로그인하고 문제에 대한 해결을 시도합니다.
잠겨 있는 VM을 재부팅할 수 있습니다.
그래도 VM에 액세스할 수 없으면 보조 NIC를 워크로드 VM에 연결하여 이 NIC에서 해당 워크로드 VM에 액세스합니다.

기본 클라우드 적용 모드에서도 PCG가 필요합니까?

예.

CSM에서 내 공용 클라우드 계정을 온보딩한 후에 PCG에 대한 IAM 역할을 변경할 수 있습니까?

예. 공용 클라우드에 적용 가능한 NSX Cloud 스크립트를 다시 실행하여 PCG 역할을 재생성할 수 있습니다. PCG 역할을 재생성한 후 새 역할 이름을 사용하여 CSM에서 공용 클라우드 계정을 편집합니다. 공용 클라우드 계정에 배포된 모든 새 PCG 인스턴스에 새 역할이 사용됩니다.

기존 PCG 인스턴스는 이전 PCG 역할을 계속 사용합니다. 기존 PCG 인스턴스에 대한 IAM 역할을 업데이트하려면 공용 클라우드로 이동하여 해당 PCG 인스턴스에 대한 역할을 수동으로 변경합니다.

NSX Cloud에 대해 NSX-T Data Center 온-프레미스 라이센스를 사용할 수 있습니까?

예. ELA에 대한 조항이 있는 경우 가능합니다.

CSM의 URL을 사용하여 PCG를 배포하려고 하지만 게이트웨이 이름을 확인할 수 없기 때문에 오류가 발생합니다.

PCG를 설치하기 위한 CSM UI의 URL이 게이트웨이 이름을 확인할 수 없어서 실패하는 경우 워크로드 VM의 OS에 대해 해당 공용 클라우드에서 다음을 수행합니다.

Microsoft Azure의 Microsoft Windows 워크로드 VM에서 다음 명령을 실행하고 CSM의 URL을 사용하여 설치 스크립트를 다시 다운로드합니다.
```
Add-DnsClientNrptRule -Namespace "nsx-gw.vmware.local" -NameServers "168.63.129.16" -DnsSecEnable
```
AWS의 Microsoft Windows 워크로드 VM에서 다음 명령을 실행하고 CSM의 URL을 사용하여 설치 스크립트를 다시 다운로드합니다.
```
Add-DnsClientNrptRule -Namespace "nsx-gw.vmware.local" -NameServers "169.254.169.253" -DnsSecEnable
```
Microsoft Azure의 Linux 워크로드 VM에서 다음 명령을 실행하여 PCG의 IP 주소를 다운로드하고 CSM의 URL에서 이러한 IP 주소를 사용하여 설치 스크립트를 다운로드합니다.
```
nslookup nsx-gw.vmware.local 168.63.129.16 | awk '/^Address: / { print $2 }'
```
AWS의 Linux 워크로드 VM에서 다음 명령을 실행하여 PCG의 IP 주소를 다운로드하고 CSM의 URL에서 이러한 IP 주소를 사용하여 설치 스크립트를 다운로드합니다.:
```
nslookup nsx-gw.vmware.local 169.254.169.253 | awk '/^Address: / { print $2 }'
```