NSX Cloud FAQs and Troubleshooting

How can I reinstall NSX Tools on Windows VM?

To reinstall NSX Tools on the Windows VM:

Uninstall the existing NSX Tools on the Windows VM. For details, see Uninstalling NSX Tools.
Reboot the Windows VM.
Important: If you do not reboot the Windows VM after uninstalling the NSX Tools, reinstall can cause undesired behavior.
Reinstall the NSX Tools using the installation command. For details, see Install NSX Tools on Windows VMs.

How can I access the nsxcli commands after installing NSX Tools?

After installing NSX Tools on the Linux VM:

Log in to the Linux VM where you have installed NSX Tools.
Run the sudo service nsx-agent-chroot nsx-exec bash command. You will be directed to bash shell.
now run the nsxcli command. You will be directed to the nsxcli prompt.

You can now execute any required nsxcli commands like get firewall rules and so on.

After installing NSX Tools on the Windows VM:

Log in to the Windows VM where you have installed NSX Tools.
Open PowerShell.
On the PowerShell prompt, run the nsxcli command. You will be directed to the nsxcli prompt.

You can now execute any required nsxcli commands like get firewall rules and so on.

How can I verify that my NSX Cloud components are installed and running?

To verify that NSX Tools on your workload VM are connected to PCG, do the following:
1. Type the nsxcli command to open NSX CLI.
2. Type the following command to get the gateway connection status, for example:
```
get gateway connection status
Public Cloud Gateway  : nsx-gw.vmware.com:5555
Connection Status 	: ESTABLISHED 
```
The workload VMs must have the correct tags to connect to PCG:
1. Log in to the AWS console or the Microsoft Azure portal.
2. Verify the VM's eth0 or interface tag.
  The nsx.network key must have the value default.

My VMs launched using cloud-init are quarantined and do not allow installation of third-party tools. What should I do?

With the Quarantine Policy enabled, when launching VMs using cloud-init scripts with the following specifications, your VMs are quarantined upon launching and you are not able to install custom applications or tools on them:

tagged with nsx.network=default
custom services auto-installed or bootstrapped when the VM is powered on

Solution:

Update the default (AWS) or default-vnet-<vnet-ID>-sg (Microsoft Azure) security group to add inbound/outbound ports as required for the installation of custom or third-party applications.

I tagged my VM correctly and installed NSX Tools, but my VM is quarantined. What should I do?

If you encounter this problem, try the following:

Check whether the NSX Cloud tag: nsx.network and its value: default are correctly typed in. This is case-sensitive.
Resync the AWS or Microsoft Azure account from CSM:
- Log in to CSM.
- Go to Clouds > AWS/Azure > Accounts.
- Click on Actions from the public cloud account tile and click Resync Account.

What should I do if I cannot access my workload VM?

From your Public Cloud (AWS or Microsoft Azure):

Ensure that all ports on the VM, including those managed by NSX Cloud, the OS firewall (Microsoft Windows or IPTables), and NSX are properly configured in order to allow traffic,

For example, to allow ping to a VM, the following needs to be properly configured:
- Security Group on AWS or Microsoft Azure. See Threat Detection using the NSX Cloud Quarantine Policy for more information.
- NSX DFW rules. See Default Connectivity Strategy for NSX-Managed Workload VMs in the NSX Enforced Mode for details.
- Windows Firewall or IPTables on Linux.
Attempt resolving the issue by logging in to the VM using SSH or other methods, for example, the Serial Console in Microsoft Azure.
You can reboot the locked out VM.
If you still cannot access the VM, then attach a secondary NIC to the workload VM from which to access that workload VM.

Do I need a PCG even in the Native Cloud Enforced Mode?

Yes.

Can I change the IAM role for the PCG after I have onboarded my public cloud account in CSM?

Yes. You can rerun the NSX Cloud script applicable to your public cloud to regenerate the PCG role. Edit your public cloud account in CSM with the new role name after you regenerate the PCG role. Any new PCG instances deployed in your public cloud account will use the new role.

Note that existing PCG instances continue to use the old PCG role. If you want to update the IAM role for an existing PCG instance, go to your public cloud and manually change the role for that PCG instance.

Can I use the NSX on-premises licenses for NSX Cloud?

Yes, you can if your ELA has a clause for it.

I am using the URL from CSM to deploy PCG but I get an error because the gateway name is unresolvable.

When the URL from the CSM UI for installing PCG fails because of gateway name being unresolvable, do the following in the respective public cloud for the OS of your workload VM:

On Microsoft Windows workload VMs in Microsoft Azure, run the following command and download the install script again using the URL from CSM:
```
Add-DnsClientNrptRule -Namespace "nsx-gw.vmware.local" -NameServers "168.63.129.16" -DnsSecEnable
```
On Microsoft Windows workload VMs in AWS, run the following command and download the install script again using the URL from CSM:
```
Add-DnsClientNrptRule -Namespace "nsx-gw.vmware.local" -NameServers "169.254.169.253" -DnsSecEnable
```
On Linux workload VMs in Microsoft Azure run the following command to get PCG's IP addresses and download the install script using these IP addresses with the URL from CSM.
```
nslookup nsx-gw.vmware.local 168.63.129.16 | awk '/^Address: / { print $2 }'
```
On Linux workload VMs in AWS run the following command to get PCG's IP addresses and download the install script using these IP addresses with the URL from CSM.:
```
nslookup nsx-gw.vmware.local 169.254.169.253 | awk '/^Address: / { print $2 }'
```

How to connect CSM to MP using CA Certificate?

In the NSX Cloud setups, CSM connects to MP through a self-signed certificate. Instead of a self-signed certificate, you can use a CA-signed certificate, if required.

To use a CA-signed certificate, perform the following steps:

Log into the CSM appliance as a root user.
Copy the root CA cert pem file into CSM.
Get the Java KeyStore (JKS) password from the file as follows.
```
PASSWORD=`cat /config/http/.http_cert_pw`
```
Add the root CA certificate to the CSM JKS store using the following command.
```
keytool -importcert -file /root/myCA.pem -noprompt -alias nsx_mgmr_custom -storetype JKS -keystore /usr/java/jre/lib/security/cacerts -storepass $PASSWORD
```
Note: This example uses /root/myCA.pem. You must use path for your root CA cert pem file.

Check if alias is added using the following command.

keytool -list -v -keystore /usr/java/jre/lib/security/cacerts -storepass $PASSWORD | grep
        nsx_mgmr_custom

The command lists out the newly added CA certificates. This is used between CSM and NSX Manager.

The root CA certificate is now considered as valid, the CSM and NSX Manager can peer.