Preguntas frecuentes y solución de problemas de NSX Cloud

Este tema incluye algunas preguntas frecuentes e información sobre solución de problemas.

¿Cómo puedo volver a instalar NSX Tools en la máquina virtual Windows?

Para volver a instalar NSX Tools en la máquina virtual Windows:

Desinstale la instancia actual de NSX Tools en la máquina virtual Windows. Para obtener más información, consulte Desinstalar NSX Tools.
Reinicie la máquina virtual Windows.
Importante: Si no reinicia la máquina virtual Windows después de desinstalar NSX Tools, la reinstalación puede provocar un comportamiento no deseado.
Vuelva a instalar NSX Tools mediante el comando de instalación. Para obtener más información, consulte Instalar NSX Tools en máquinas virtuales Windows.

¿Cómo puedo acceder a los comandos nsxcli después de instalar NSX Tools?

Después de instalar NSX Tools en la máquina virtual Linux:

Inicie sesión en la máquina virtual Linux en la que ha instalado NSX Tools.
Ejecute el comando sudo service nsx-agent-chroot nsx-exec bash. Se le redirigirá al bash shell.
Ejecute el comando nsxcli. Se le dirigirá a la línea de comandos de nsxcli.

Ahora puede ejecutar los comandos nsxcli necesarios, como get firewall rules, entre otros.

Después de instalar NSX Tools en la máquina virtual de Windows:

Inicie sesión en la máquina virtual de Windows en la que ha instalado NSX Tools.
Abra PowerShell.
En la línea de comandos de PowerShell, ejecute el comando nsxcli. Se le dirigirá a la línea de comandos de nsxcli.

Ahora puede ejecutar los comandos nsxcli necesarios, como get firewall rules, entre otros.

¿Cómo puedo verificar que los componentes de NSX Cloud están instalados y en ejecución?

Para comprobar que NSX Tools en la máquina virtual de carga de trabajo esté conectado a PCG, haga lo siguiente:
1. Escriba el comando nsxcli para abrir la CLI de NSX.
2. Escriba el siguiente comando para obtener el estado de conexión de la puerta de enlace, por ejemplo:
```
get gateway connection status
Public Cloud Gateway  : nsx-gw.vmware.com:5555
Connection Status 	: ESTABLISHED 
```
Las máquinas virtuales de carga de trabajo deben tener las etiquetas adecuadas para conectarse a la PCG:
1. Inicie sesión en la consola de AWS o el portal de Microsoft Azure.
2. Compruebe la etiqueta eth0 o la etiqueta de interfaz de la máquina virtual.
  La clave nsx.network debe tener el valor default.

Las máquinas virtuales iniciadas con cloud-init se ponen en cuarentena y no permiten la instalación de herramientas de terceros. ¿Qué debo hacer?

Con la directiva de cuarentena habilitada, cuando se inician máquinas virtuales mediante scripts cloud-init con las siguientes especificaciones, las máquinas virtuales se ponen en cuarentena al iniciarse y no se pueden instalar en ellas aplicaciones o herramientas personalizadas:

etiquetado con nsx.network=default
servicios personalizados arrancados o instalados automáticamente cuando la máquina virtual está encendida

Solución:

Actualice el grupo de seguridad default (AWS) o default-vnet-<vnet-ID>-sg (Microsoft Azure) para agregar puertos entrantes y salientes según sea necesario para la instalación de aplicaciones personalizadas o de terceros.

Etiqueté mi máquina virtual correctamente e instalé NSX Tools, pero la máquina virtual está en cuarentena. ¿Qué debo hacer?

Si se detecta este problema, intente lo siguiente:

Compruebe si la etiqueta: nsx.network de NSX Cloud y su valor default están escritos correctamente. Se distinguen mayúsculas de minúsculas.
Vuelva a sincronizar la cuenta de AWS o Microsoft Azure desde CSM:
- Inicie sesión en CSM.
- Vaya a Nubes > AWS/Azure > Cuentas.
- Haga clic en Acciones en el mosaico de la cuenta de nube pública y haga clic en Volver a sincronizar cuenta.

¿Qué debo hacer si no tengo acceso a la máquina virtual de carga de trabajo?

Desde la nube pública (AWS o Microsoft Azure):

Asegúrese de que todos los puertos en la máquina virtual, incluidos los administrados por NSX Cloud, el firewall del sistema operativo (Microsoft Windows o IPTables) y NSX-T Data Center estén correctamente configurados para permitir tráfico.

Por ejemplo, para permitir ping en una máquina virtual, deberá configurarse correctamente lo siguiente:
- Grupo de seguridad en AWS o Microsoft Azure. Consulte Detección de amenazas mediante la directiva de cuarentena de NSX Cloud para obtener más información.
- Reglas de DFW de NSX-T Data Center. Consulte Estrategia de conectividad predeterminada para las máquinas virtuales de carga de trabajo administradas por NSX en Modo forzado de NSX para obtener detalles.
- Firewall de Windows o IPTables en Linux.
Intente resolver el problema iniciando sesión en la máquina virtual mediante SSH u otros métodos, por ejemplo, la consola serie en Microsoft Azure.
Puede reiniciar la máquina virtual bloqueada.
Si aún no puede acceder a la máquina virtual, asocie una NIC secundaria a la máquina virtual de carga de trabajo desde la que se pueda acceder a esa máquina virtual de carga de trabajo.

¿Necesito una PCG incluso en Modo forzado de nube nativa?

Sí.

¿Se puede cambiar la función de IAM para la PCG después de incorporar mi cuenta de nube pública en CSM?

Sí. Puede volver a ejecutar el script de NSX Cloud correspondiente a la nube pública para volver a generar la función de PCG. Edite la cuenta de nube pública en CSM con el nuevo nombre de función después de volver a generar la función de PCG. Cualquier nueva instancia de PCG implementada en su cuenta de nube pública utilizará la nueva función.

Tenga en cuenta que las instancias de PCG existentes seguirán utilizando la función de PCG anterior. Si desea actualizar la función de IAM para una instancia de PCG existente, vaya a la nube pública y cambie manualmente la función de esa instancia de PCG.

¿Puedo usar las licencias locales de NSX-T Data Center con NSX Cloud?

Sí, puede si su ELA tiene una cláusula al respecto.

Estoy utilizando la URL de CSM para implementar la PCG, pero aparece un error porque el nombre de la puerta de enlace no se puede resolver.

Cuando falla la URL de la interfaz de usuario de CSM para instalar la PCG debido a que el nombre de la puerta de enlace no se puede resolver, haga lo siguiente en la nube pública correspondiente para el sistema operativo de la máquina virtual de carga de trabajo:

En las máquinas virtuales de carga de trabajo de Microsoft Windows en Microsoft Azure, ejecute el siguiente comando y vuelva a descargar el script de instalación usando la URL desde CSM:
```
Add-DnsClientNrptRule -Namespace "nsx-gw.vmware.local" -NameServers "168.63.129.16" -DnsSecEnable
```
En las máquinas virtuales de carga de trabajo de Microsoft Windows en AWS, ejecute el siguiente comando y vuelva a descargar el script de instalación usando la URL desde CSM:
```
Add-DnsClientNrptRule -Namespace "nsx-gw.vmware.local" -NameServers "169.254.169.253" -DnsSecEnable
```
En las máquinas virtuales de carga de trabajo de Linux en Microsoft Azure, ejecute el siguiente comando para obtener las direcciones IP de la PCG y descargar el script de instalación usando estas direcciones IP con la URL desde CSM.
```
nslookup nsx-gw.vmware.local 168.63.129.16 | awk '/^Address: / { print $2 }'
```
En las máquinas virtuales de carga de trabajo de Linux en AWS, ejecute el siguiente comando para obtener las direcciones IP de la PCG y descargar el script de instalación usando estas direcciones IP con la URL desde CSM.:
```
nslookup nsx-gw.vmware.local 169.254.169.253 | awk '/^Address: / { print $2 }'
```

¿Cómo se conecta CSM a MP mediante un certificado de CA?

En las configuraciones de NSX Cloud, CSM se conecta a MP a través de un certificado autofirmado. En lugar de un certificado autofirmado, puede usar un certificado firmado por una CA, si fuera necesario.

Para usar un certificado firmado por una CA, siga estos pasos:

Inicie sesión en el dispositivo de CSM como usuario root.
Copie el archivo CA cert pem raíz en CSM.
Obtenga la contraseña del almacén de claves de Java (Java KeyStore, JKS) del archivo de la siguiente forma.
```
PASSWORD=`cat /config/http/.http_cert_pw`
```
Agregue el certificado de CA raíz al almacén JKS ce CSM mediante el siguiente comando.
```
keytool -importcert -file /root/myCA.pem -noprompt -alias nsx_mgmr_custom -storetype JKS -keystore /usr/java/jre/lib/security/cacerts -storepass $PASSWORD
```
Nota: Este ejemplo usa /root/myCA.pem. Debe utilizar la ruta del archivo CA cert pem raíz.

Compruebe si se agregó el alias mediante el siguiente comando.

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

El comando mostrará los certificados de CA recién agregados. Esto se utiliza entre CSM y NSX Manager.

El certificado de CA raíz ahora se considerará válido, y CSM y NSX Manager se podrán emparejar.