Risoluzione dei problemi relativi ai profili host e ai profili dei nodi di trasporto quando vengono utilizzati per distribuire automaticamente cluster stateless.
| Scenario | Descrizione |
|---|---|
| Quando più adattatori VMkernel abilitati per supportare il traffico di gestione, vMotion e di altro tipo vengono fatti migrare allo stesso commutatore logico, gli adattatori VMkernel vengono fatti migrare al commutatore logico dopo il riavvio. Ma il servizio in un adattatore VMkernel è abilitato in un adattatore diverso. |
Ad esempio, prima della migrazione, vmk0 è abilitato per supportare il traffico di gestione e vmk1 è abilitato per il traffico di vMotion. Dopo il riavvio dell'host, vmk0 supporta il traffico vMotion e vmk1 supporta il traffico di gestione. Ciò genera un errore di non conformità dopo il riavvio. Soluzione: nessuna. Non vi è alcun impatto in quanto entrambi gli adattatori VMkernel si trovano nello stesso commutatore logico. |
| L'avanzamento della preparazione dell'host si blocca al 60% mentre lo stato del nodo visualizza UP. | Problema: quando viene applicato un TNP in un cluster, NSX viene installato correttamente nell'host e lo stato del nodo visualizza UP, ma la GUI mostra ancora uno stato di avanzamento al 60%. Soluzione: applicare nuovamente la configurazione TNP o TN senza alcuna modifica nella configurazione. In questo modo, lo stato viene corretto al 100% nella GUI. |
| Anche se la migrazione di VMkernel riesce, si è verificato un errore di convalida nel TN prima che i commutatori host vengano rimossi. |
Problema: quando si esegue la migrazione dell'interfaccia di gestione vmk0 da vSwitch a un commutatore logico, NSX viene installato correttamente nell'host. La migrazione di Vmkernel avviene correttamente, ma lo stato di TN indica un'operazione parzialmente riuscita con errore. Validation before host switches removal failed: [error: No management vmk will have PNIC after ['vmk1'] in ['9a bb eb c1 04 81 40 e2-bc 3f 3e aa bd 14 62 1e'] lose all PNICs.]; LogicalSwitch full-sync: LogicalSwitch full-sync realization query skipped. Soluzione: nessuna. Ignorare il messaggio di errore quando la migrazione di VMkernel è riuscita. |
| Se si applica nuovamente un protocollo TNP in cui la mappatura di rete per l'installazione riporta vmk0, l'host perde la connettività. | Problema: quando una configurazione TNP è costituita da vmk0 nella mappatura di rete per l'installazione, gli host perdono la connettività. Soluzione: anziché applicare nuovamente il TNP, riavviare l'host con le configurazioni necessarie in TNP. |
| Impossibile applicare il profilo host perché i criteri della password dell'utente MUX e la password non sono stati reimpostati. | Problema: solo negli host che eseguono versioni precedenti a vSphere 6.7 U3. L'applicazione negli host per la correzione dell'host e del profilo host potrebbe non riuscire a meno che la password di mux_user non venga reimpostata. Soluzione: in Criteri e profili, modificare il profilo host per modificare il criterio della password di mux_user e reimpostare la password mux_user. |
| Il profilo host non è portabile. | Problema: nessuno dei vCenter server può utilizzare il profilo host contenente la configurazione di NSX. Soluzione: nessuna. |
| Distribuire automaticamente il motore regole | Problema: il profilo host non può essere utilizzato nelle regole di distribuzione automatica per distribuire nuovi cluster. Se vengono distribuiti nuovi cluster, gli host vengono distribuiti con servizi di rete di base e rimangono in modalità di manutenzione. Soluzione: preparare ogni cluster dalla GUI di NSX. Vedere Applicare TNP in cluster stateless. |
| Controllare gli errori di conformità. | Problema: la correzione del profilo host non può risolvere gli errori di conformità relativi alla configurazione di NSX.
Soluzione: assicurarsi che la configurazione di NSX corrisponda in profilo host e in TNP. Riavviare l'host per realizzare le modifiche alla configurazione. Viene visualizzato l'host. |
| Correzione | Problema: se sono presenti errori di conformità specifici di NSX, la correzione del profilo host in tale cluster viene bloccata. Configurazione non corretta:
Soluzione: assicurarsi che la configurazione di NSX corrisponda in profilo host e TNP. Riavviare l'host per realizzare le modifiche alla configurazione. Viene visualizzato l'host. |
| Collegare | Problema: in un cluster configurato con NSX, il profilo host non può essere collegato a livello di host. Soluzione: nessuna. |
| Scollegare | Problema: lo scollegamento e il collegamento di un nuovo profilo host in un cluster configurato con NSX non rimuove la configurazione di NSX. Anche se il cluster è conforme al profilo host appena collegato, ha comunque la configurazione NSX di un profilo precedente. Soluzione: nessuna. |
| Aggiornare | Problema: se l'utente ha modificato la configurazione di NSX nel cluster, estrarre un nuovo profilo host. Aggiornare manualmente il profilo host per tutte le impostazioni perse. Soluzione: nessuna. |
| Configurazione del nodo di trasporto a livello di host | Problema: dopo che un nodo di trasporto è stato distribuito automaticamente, agisce come una singola entità. Qualsiasi aggiornamento di tale nodo di trasporto potrebbe non corrispondere a TNP. Soluzione: aggiornare il cluster. Qualsiasi aggiornamento in un nodo di trasporto autonomo non può mantenere la sua specifica di migrazione. La migrazione potrebbe non riuscire a registrare il riavvio. |
| La configurazione di PeerDNS non è supportata nell'adattatore VMkernel selezionato per la migrazione al commutatore NVDS. | Problema: se un adattatore VMkernel selezionato per la migrazione a NVDS è abilitato per il DNS peer, l'applicazione del profilo host non riesce. Soluzione: modificare il profilo host estratto disabilitando l'impostazione DNS peer nell'adattatore VMkernel che deve essere migrato in un commutatore NVDS. In alternativa, assicurarsi di non migrare gli adattatori VMkernel abilitati per il DNS peer in un commutatore NVDS. |
| L'indirizzo DHCP dell'indirizzo della NIC di VMkernel non viene mantenuto | Problema: se l'host di riferimento è stateful, tutti gli host stateless che utilizzano un profilo estratto dall'host di riferimento stateful non possono conservare il proprio indirizzo MAC di gestione VMkernel derivato da MAC avviato da PXE. Ciò comporta problemi di indirizzamento DHCP. Soluzione: modificare il profilo host estratto dell'host stateful e modificare "Determina come impostare l'indirizzo MAC per vmknic" in "Usa l'indirizzo MAC da cui il sistema è stato avviato con PXE". |
| Un errore dell'applicazione profilo host in vCenter può causare errori di configurazione NSX nell'host. | Problema: se l'applicazione del profilo host non riesce in vCenter, potrebbe non riuscire nemmeno la configurazione di NSX. Soluzione: in vCenter, verificare che il profilo host sia stato applicato correttamente. Correggere gli errori e riprovare. |
| I LAG non sono supportati negli host ESXi stateless. | Problema: il profilo di uplink configurato come LAG in NSX non è supportato in un host di ESXi stateless gestito da un vCenter Server o in NSX. Soluzione: nessuna. |
| Un host stateless non viene avviato con l'indirizzo MAC della scheda NIC PXE quando viene applicato con un profilo host estratto da un host stateful. | Problema: se un host stateless viene collegato a un profilo host estratto da un host stateful, l'adattatore VMkernel (vmknic) dell'host stateless non si avvia con l'indirizzo MAC della scheda NIC PXE dell'host perché un host stateful non viene avviato come sistema abilitato per PXE. Soluzione: quando si configura la distribuzione automatica di host stateless, assicurarsi che il profilo host estratto venga estratto da un host che si avvia come sistema abilitato per PXE. |
