NSX Cloud Domande frequenti e risoluzione dei problemi

Questo argomento copre alcune domande frequenti e informazioni sulla risoluzione dei problemi.

Come è possibile reinstallare NSX Tools in una macchina virtuale Windows?

Per reinstallare NSX Tools nella macchina virtuale Windows:

Disinstallare l'istanza di NSX Tools esistente nella macchina virtuale Windows. Per informazioni dettagliate, vedere Disinstallazione di NSX Tools.
Riavviare la macchina virtuale Windows.
Importante: Se non si riavvia la macchina virtuale Windows dopo la disinstallazione di NSX Tools, la reinstallazione può causare un comportamento indesiderato.
Reinstallare NSX Tools utilizzando il comando di installazione. Per informazioni dettagliate, vedere Installazione di NSX Tools in macchine virtuali Windows.

Come è possibile accedere ai comandi nsxcli dopo l'installazione di NSX Tools?

Dopo l'installazione di NSX Tools nella macchina virtuale Linux:

Accedere alla macchina virtuale Linux in cui è installato NSX Tools.
Eseguire il comando sudo service nsx-agent-chroot nsx-exec bash. Si verrà indirizzati alla shell bash.
Eseguire il comando nsxcli. Si verrà indirizzati al prompt nsxcli.

Ora è possibile eseguire tutti i comandi nsxcli necessari, come get firewall rules e così via.

Dopo l'installazione di NSX Tools nella macchina virtuale Windows:

Accedere alla macchina virtuale Windows in cui è installato NSX Tools.
Aprire PowerShell.
Nel prompt di PowerShell, eseguire il comando nsxcli. Si verrà indirizzati al prompt nsxcli.

Ora è possibile eseguire tutti i comandi nsxcli necessari, come get firewall rules e così via.

Come posso verificare che i componenti di NSX Cloud siano installati e in esecuzione?

Per verificare che NSX Tools nella macchina virtuale del carico di lavoro sia connesso a PCG, eseguire i passaggi seguenti:
1. Digitare il comando nsxcli per aprire la CLI di NSX.
2. Digitare il comando seguente per ottenere lo stato di connessione del gateway, ad esempio:
```
get gateway connection status
Public Cloud Gateway  : nsx-gw.vmware.com:5555
Connection Status 	: ESTABLISHED 
```
Le macchine virtuali del carico di lavoro devono disporre dei tag corretti per connettersi a PCG:
1. Accedere alla console di AWS o al portale di Microsoft Azure.
2. Verificare il tag eth0 o di interfaccia della macchina virtuale.
  La chiave di nsx.network deve avere il valore default.

Le macchine virtuali personali avviate utilizzando cloud-init vengono messe in quarantena e non consentono l'installazione di strumenti di terzi. Cosa devo fare?

Se il criterio di quarantena è abilitato, quando si avviano macchine virtuali utilizzando gli script cloud-init con le specifiche seguenti, le macchine virtuali vengono messe in quarantena all'avvio e non è possibile installare su di esse applicazioni o strumenti personalizzati:

contrassegnati con nsx.network=default
servizi personalizzati installati automaticamente o sottoposti a bootstrap all'accensione della macchina virtuale

Soluzione:

Aggiornare il gruppo di sicurezza default (AWS) o default-vnet-<vnet-ID>-sg (Microsoft Azure) per aggiungere le porte in entrata/uscita necessarie per l'installazione di applicazioni personalizzate o di terzi.

Ho taggato correttamente la mia macchina virtuale e ho installato NSX Tools, ma la macchina virtuale è stata messa in quarantena. Cosa devo fare?

Se si verifica questo problema, provare a eseguire le operazioni seguenti:

Verificare se il tag di NSX Cloud: nsx.network e il relativo valore: default sono stati digitati correttamente. Questa operazione fa distinzione tra maiuscole e minuscole.
Sincronizzare di nuovo l'account AWS o Microsoft Azure da CSM:
- Accedere a CSM.
- Passare a Cloud > AWS/Azure > Account.
- Fare clic su Azioni dal riquadro dell'account cloud pubblico e fare clic su Risincronizza account.

Che cosa devo fare se non riesco ad accedere alla macchina virtuale del carico di lavoro?

Dal cloud pubblico (AWS o Microsoft Azure):

Verificare che tutte le porte della macchina virtuale, incluse quelle gestite da NSX Cloud, il firewall del sistema operativo (Microsoft Windows o IPTables) e le NSX siano configurate correttamente per consentire il traffico.

Ad esempio, per consentire l'invio di un ping a una macchina virtuale, è necessario configurare correttamente quanto segue:
- Il gruppo di sicurezza in AWS o Microsoft Azure. Per ulteriori informazioni, consultare Rilevamento delle minacce mediante il criterio di quarantena NSX Cloud.
- Le regole DFW di NSX. Per dettagli, consultare Strategia di connettività predefinita per le macchine virtuali del carico di lavoro gestite da NSX in Modalità NSX applicato.
- Windows Firewall o IPTables in Linux.
Tentare di risolvere il problema accedendo alla macchina virtuale utilizzando SSH o altri metodi, ad esempio la console seriale in Microsoft Azure.
È possibile riavviare la macchina virtuale bloccata.
Se non è ancora possibile accedere alla macchina virtuale, collegare una scheda NIC secondaria alla macchina virtuale del carico di lavoro da cui potervi accedere.

Ho bisogno di un PCG anche in Modalità Cloud applicato nativo?

Sì.

Posso modificare il ruolo IAM per il PCG dopo aver eseguito l'onboarding dell'account personale del cloud pubblico in CSM?

Sì. È possibile eseguire nuovamente lo script di NSX Cloud applicabile al cloud pubblico per rigenerare il ruolo di PCG. Modificare l'account cloud pubblico in CSM con il nome del nuovo ruolo dopo aver rigenerato il ruolo PCG. Tutte le nuove istanze di PCG distribuite nell'account cloud pubblico utilizzeranno il nuovo ruolo.

Si noti che le istanze di PCG esistenti continuano a utilizzare il ruolo PCG precedente. Se si desidera aggiornare il ruolo IAM per un'istanza di PCG esistente, passare al cloud pubblico e modificare manualmente il ruolo per tale istanza di PCG.

Posso usare le licenze locali di NSX per NSX Cloud?

Sì, è possibile se l'ELA include una clausola relativa a tale eventualità.

Utilizzo l'URL di CSM per distribuire PCG, ma si verifica un errore perché il nome del gateway non è risolvibile.

Quando l'URL dell'interfaccia utente di CSM per l'installazione di PCG non riesce a causa di un nome di gateway non risolvibile, eseguire le operazioni seguenti nel cloud pubblico corrispondente per il sistema operativo della macchina virtuale del carico di lavoro:

Nelle macchine virtuali del carico di lavoro di Microsoft Windows in Microsoft Azure, eseguire il comando seguente e scaricare nuovamente lo script di installazione utilizzando l'URL di CSM:
```
Add-DnsClientNrptRule -Namespace "nsx-gw.vmware.local" -NameServers "168.63.129.16" -DnsSecEnable
```
Nelle macchine virtuali del carico di lavoro di Microsoft Windows in AWS, eseguire il comando seguente e scaricare nuovamente lo script di installazione utilizzando l'URL di CSM:
```
Add-DnsClientNrptRule -Namespace "nsx-gw.vmware.local" -NameServers "169.254.169.253" -DnsSecEnable
```
Nelle macchine virtuali del carico di lavoro di Linux in Microsoft Azure eseguire il comando seguente per ottenere gli indirizzi IP del PCG e scaricare lo script di installazione utilizzando questi indirizzi IP con l'URL di CSM.
```
nslookup nsx-gw.vmware.local 168.63.129.16 | awk '/^Address: / { print $2 }'
```
Nelle macchine virtuali del carico di lavoro di Linux in AWS eseguire il comando seguente per ottenere gli indirizzi IP di PCG e scaricare lo script di installazione utilizzando questi indirizzi IP con l'URL di CSM.:
```
nslookup nsx-gw.vmware.local 169.254.169.253 | awk '/^Address: / { print $2 }'
```

Come connettere CSM a MP utilizzando il certificato CA?

Nelle configurazioni di NSX Cloud, CSM si connette a MP tramite un certificato autofirmato. Invece di un certificato autofirmato, è possibile utilizzare un certificato firmato da un'autorità di certificazione, se necessario.

Per utilizzare un certificato firmato da un'autorità di certificazione, eseguire i passaggi seguenti:

Accedere all'appliance di CSM come utente root.
Copiare il file pem del certificato CA root in CSM.
Ottenere la password di Java KeyStore (JKS) dal file come indicato di seguito.
```
PASSWORD=`cat /config/http/.http_cert_pw`
```
Aggiungere il certificato CA root all'archivio JKS CSM utilizzando il comando seguente.
```
keytool -importcert -file /root/myCA.pem -noprompt -alias nsx_mgmr_custom -storetype JKS -keystore /usr/java/jre/lib/security/cacerts -storepass $PASSWORD
```
Nota: Questo esempio utilizza /root/myCA.pem. È necessario utilizzare il percorso per il file pem del certificato CA root.

Controllare se l'alias viene aggiunto utilizzando il comando seguente.

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

Il comando elenca i certificati CA appena aggiunti. Questo valore viene utilizzato tra CSM e NSX Manager.

Il certificato CA root è ora considerato come valido, ma è possibile eseguire il peering tra CSM e NSX Manager.