È possibile eseguire la migrazione della distribuzione di VMware Integrated OpenStack (VIO) da NSX-V a NSX-T. Durante la migrazione, il piano di controllo VIO deve essere in modalità di sola lettura.
La connettività del percorso dati per le macchine virtuali non è influenzata durante la migrazione, ad eccezione di brevi interruzioni durante il cutover del traffico nord-sud e la migrazione degli host. Questa migrazione deve essere eseguita durante un'unica finestra di manutenzione.
Panoramica del processo di migrazione
- Installare NSX-T.
- Preparare NSX-T per VIO. Questo richiede la configurazione di gateway di livello 0 o VRF-Lite per le reti esterne, nonché la configurazione di cluster Edge, profili del server DHCP e proxy di metadati. Per ulteriori informazioni, vedere https://docs.vmware.com/it/VMware-Integrated-OpenStack/index.html.
- Ottenere il bundle dell'utilità di migrazione Neutron, che fa parte dei prodotti VIO.
- Configurare l'utilità di migrazione Neutron.
- Distribuire il pod dell'utilità di migrazione Neutron.
- Dall'interfaccia utente di NSX Manager:
- Avviare la migrazione completa dell'Edge.
- Gestire il feedback e completare la migrazione.
- Avviare la migrazione dell'host.
- Gestire il feedback e completare la migrazione.
- Attendere il completamento del pod dell'utilità di migrazione Neutron.
- Eliminare la distribuzione dell'utilità di migrazione Neutron.
- Rimuovere l'installazione di VIO in NSX-V.
Prerequisiti
- VIO 7.2.0 o versioni successive
- NSX-V 6.4.11 o versioni successive
- vSphere 6.7 o versione successiva (è consigliabile aggiornare gli host ESXi alla versione 7.0 o successiva prima della migrazione).
- Numero di coppie di indirizzi consentite in Neutron (il numero di binding di indirizzi manuali non deve essere superiore a 128).
- Numero di subnet multiple con DHCP per commutatore logico (ne è consentita solo una in NSX-T).
- Numero di uplink del router per rete (solo uno in NSX-T).
- Gruppi di host: se l'alta disponibilità per i nodi NSX Edge è abilitata e sono stati specificati gruppi di host per i nodi Edge da posizionare. Verrà generato un avviso.
- L'alta disponibilità Edge viene ignorata in NSX-T perché non è applicabile. Verrà generato un avviso.
- Le reti di provider o le reti esterne basate su un gruppo di porte DVS non sono supportate nel plug-in NSX-T.
- Non sono supportate più reti fornitori VLAN.
- Le topologie di bilanciamento del carico non sono supportate dal plug-in NSX-T (ad esempio un bilanciamento del carico con membri di varie subnet senza uplink allo stesso router Edge o un bilanciamento del carico in una rete non connessa a un router Neutron).
- Utilizzo di indirizzi non validi per NSX-T, ad esempio si sovrappongono alla rete di transito.
- Macchine virtuali distribuite su reti esterne. Non funzionano su NSX-T.
- Raggiungibilità delle subnet per i membri del bilanciamento del carico. NSX-T richiede che tutte le subnet del bilanciamento del carico siano connesse allo stesso gateway.
In NSX-T non devono essere presenti risorse di proprietà di OpenStack, ad esempio risorse provenienti da una distribuzione VIO precedente nell'istanza di NSX-T.
Vedere Migrazione sul posto di parti specifiche di NSX-V per le preparazioni necessarie per la migrazione completa dell'Edge e la migrazione dell'host.
Preparazione per la migrazione - Dimensionamento del cluster Edge NSX-T
- Per ogni OpenStack VIP, trovare la subnet corrispondente e recuperare il router verso il quale è eseguito l'uplink, a meno che la subnet non si trovi in una rete esterna.
- Elencare i membri per ogni pool LB di OpenStack. Individuare la subnet a cui appartengono e recuperare il router verso cui è eseguito l'uplink della subnet.
Il numero di router trovati, insieme alle dimensioni del bilanciamento del carico di OpenStack più grande, determinerà il numero di slot LB necessari nel cluster Edge NSX-T. Per ogni LB, saranno necessari due slot per i router del servizio attivo e di standby. Fare riferimento a https://configmax.vmware.com per il numero massimo di bilanciamenti del carico che possono essere eseguiti in ogni appliance Edge NSX-T.
Preparazione per la migrazione - Configurazione del pool di IP TEP
Durante la migrazione dell'host, NSX-V e i TEP di NSX-T devono essere in grado di connettersi tra loro per garantire la connettività. È necessario configurare il pool di IP TEP di NSX-T in modo che possa instradare il traffico verso i TEP di NSX-V.
Parametri di configurazione di NSX-V non supportati in NSX-T
Nella tabella seguente sono elencati i parametri NSX-V non supportati e i motivi.
| Parametro | Descrizione | Motivo |
|---|---|---|
| cluster_moid | Elenca gli ID dei cluster utilizzati da OpenStack. | Non applicabile in NSX-T. |
| datacenter_moid |
Identifica il data center per la distribuzione di appliance edge NSX-V. | Non applicabile in NSX-T. |
| deployment_container_id |
Identifica il contenitore di distribuzione per gli NSX-V Edge. | Non applicabile in NSX-T. |
| resource_pool_id |
Identifica il pool di risorse per gli NSX-V Edge. | Non applicabile in NSX-T. |
| datastore_id |
Identifica il datastore per gli NSX-V Edge. | Non applicabile in NSX-T. |
| ha_datastore_id |
Datastore aggiuntivo se è abilitata l'alta disponibilità Edge. | Non applicabile in NSX-T. |
| ha_placement_random |
Divide gli Edge attivi tra il datastore primario e quello secondario. | Non applicabile in NSX-T. |
| edge_host_groups |
Verifica che gli Edge attivi/di backup siano posizionati nei gruppi di host elencati. | Non applicabile in NSX-T. |
| external_network |
ID di DVPG da utilizzare per l'uplink della rete fisica. | Non applicabile in NSX-T. |
| task_status_check_interval |
Intervallo per il controllo del completamento dell'attività. | Non applicabile in NSX-T. |
| vdn_scope_id |
ID dell'oggetto ambito di rete per i cavi virtuali VXLAN. | Gli ambiti VDN sono sostituiti dalle zone di trasporto overlay di NSX-T. |
| dvs_id |
ID del DVS connesso al cluster di gestione ed Edge. Anche utilizzato per impostazione predefinita per le reti VLAN. | Il DVS viene sostituito dalla zona di trasporto VLAN in NSX-T. |
| maximum_tunnels_per_vnic |
Numero massimo di interfacce secondarie supportate da una VNIC in un'appliance Edge. | Non applicabile in NSX-T. |
| backup_edge_pool |
Definisce la dimensione per il pool di NSX-V Edge che deve essere utilizzato dalla distribuzione OpenStack. | Non applicabile in NSX-T. |
| mgm_net_moid |
ID del gruppo di porte per la rete di gestione del proxy dei metadati. | Non applicabile in NSX-T. |
| mgt_net_proxy_ips |
Elenco separato da virgole degli indirizzi IP della rete di gestione. | Non applicabile in NSX-T. |
| mgt_net_proxy_netmask |
Netmask della rete di gestione per il proxy dei metadati. | Non applicabile in NSX-T. |
| mgt_net_default_gateway |
Gateway predefinito della rete di gestione per il proxy dei metadati. | Non applicabile in NSX-T. |
| nova_metadata_ips |
Indirizzi IP utilizzati dal servizio metadati Nova. | Forniti nella configurazione del proxy dei metadati di NSX-T. |
| nova_metadat_port |
Porta utilizzata dal servizio metadati Nova. | Forniti nella configurazione del proxy dei metadati di NSX-T. |
| spoofguard_enabled |
Per impostazione predefinita, spoofguard è abilitato in NSX-V, ma se si disabilita spoofguard in NSX-V, spoofguard verrà abilitato in NSX-T dopo la migrazione. | Abilitato per impostazione predefinita in NSX-T (non può essere disattivato globalmente). |
| use_exclude_list |
Utilizza il componente elenco di esclusione NSX-V quando la sicurezza della porta è disabilitata e spoofguard è abilitato. | Abilitato per impostazione predefinita in NSX-T (non può essere disattivato globalmente). |
| tenant_router_types |
Elenco ordinato di tipi di router da allocare come router del tenant. | Non applicabile in NSX-T. |
| edge_appliance_user |
Nome utente da configurare per l'accesso all'appliance Edge. | Non applicabile in NSX-T. |
| metadata_initializer |
Inizializza l'infrastruttura di accesso ai metadati. | Non applicabile in NSX-T. |
| shared_router_appliance_size |
Dimensione dell'appliance Edge da utilizzare per la creazione di un Edge router condiviso. | Non applicabile in NSX-T. |
| use_dvs_features |
Consente la configurazione diretta del supporto DVS NSX-V. | Non applicabile in NSX-T. |
| service_insertion_profile_id |
ID del profilo delle regole del firewall di reindirizzamento che verrà utilizzato per l'inserimento del servizio. | La funzionalità non esiste nell'integrazione di NSX-T. |
| service_insertion_redirect_all |
Crea una regola del firewall per reindirizzare tutto il traffico a un firewall di terze parti. | La funzionalità non esiste nell'integrazione di NSX-T. |
| use_nsx_policies |
Utilizza i criteri di sicurezza NSX per l'implementazione dei gruppi di sicurezza Neutron. | La funzionalità non esiste nell'integrazione di NSX-T. |
| default_policy_id |
Se use_nsx_policies è True, questo criterio verrà utilizzato come criterio predefinito per i nuovi tenant. |
La funzionalità non esiste nell'integrazione di NSX-T. |
| bind_floatingip_to_all_interfaces |
Associa gli IP mobili alle interfacce downlink quando è impostato su True. |
In NSX-T, NAT per IP mobile viene sempre elaborato per il traffico est-ovest. |
| vdr_transit_network |
Intervallo di rete per la connettività TLR/PLR del router distribuito. | In NSX-T, l'intervallo per la connettività DR/SR non può essere configurato da OpenStack. |
| exclusive_dhcp_edge |
Configura un Edge DHCP esclusivo per rete. | Non si applica a NSX-T perché DHCP è implementato nel cluster Edge. |
| bgp_neighbour_hold_down_timer |
Intervallo per il tempo di attesa del router adiacente BGP. | La funzionalità non esiste nell'integrazione di NSX-T. Il peering BGP viene impostato nella configurazione di routing del gateway di livello 0 di NSX. |
| bgp_neighbour_keep_alive_timer |
Intervallo per il tempo di keep alive del router adiacente. | La funzionalità non esiste nell'integrazione di NSX-T. Il peering BGP viene impostato nella configurazione di routing del gateway di livello 0 di NSX. |
| share_edges_between_tenants |
Utilizza lo stesso Edge router o DHCP per più tenant. | Non applicabile in NSX-T. |
| use_routers_as_lbaas_platform |
Utilizza il router esclusivo della subnet come piattaforma per LBaaS. | Non applicabile in NSX-T, in cui i servizi LB sono sempre collegati ai router utilizzati per l'inoltro. |
| nsx_sg_name_format |
Formato del nome NSX di un gruppo di sicurezza OpenStack. | La denominazione delle risorse di back-end è implicita in NSX-T. |
| loadbalancer_pool_transparency |
Crea pool LBaaS in modalità trasparente. | La modalità trasparente non è supportata in NSX-T. |
| default_edge_size |
Definisce le dimensioni predefinite degli Edge per router, DHCP e bilanciamento del carico. | Non applicabile in NSX-T. |
Configurazione dell'utilità di migrazione Neutron
{
"strict_validation": true,
"edge_migration": true,
"host_migration": true,
"edge_migration_interfaces_down": true,
"post_migration_cleanup": true,
"rollback": false,
"nsxv_token_lifetime": 1440,
"compute_clusters": [
"domain-c17",
"domain-c29",
"domain-c71",
],
"nsx_manager_ips": [
"192.168.16.32",
"192.168.16.64",
"192.168.16.96",
],
"nsx_manager_user": "admin",
"nsx_manager_password": "<NSX password>",
"metadata_proxy": "VIO_mdproxy",
"dhcp_profile": "VIO_dhcp_profile",
"default_overlay_tz": "0b3d2a91-2dfc-40a7-ac6b-fbd62b0e4c79",
"default_vlan_tz": "b87c7a69-6d1a-4857-badd-0d0e4d4e924f",
"default_tier0_router": "VIO_Tier0",
"availability_zones": [
{
"name": "az1",
"metadata_proxy": "VIOAZ1_mdproxy",
"dhcp_profile": "VIOAZ1_dhcp_profile",
"default_vlan_tz": "6320d1e3-45a1-4f37-87b4-6d35d19cafef",
"default_tier0_router": "VIOAZ1_Tier0VRFLite"
}
],
"external_networks_map": {
"61282e88-0abb-4036-9ea8-22418f85cdf3": "VIO_Tier0",
"39db1d0f-4279-462b-a17e-1995a5c00ae8": "VIOAZ1_Tier0VRFLite"
},
"transit_network": "100.64.0.0/16"
}
I parametri di configurazione sono:
| Parametro | Valore predefinito | Descrizione |
|---|---|---|
| post_migration_cleanup | True | Una volta completata la migrazione, rimuovere le entità NSX-T aggiuntive create dal processo di migrazione che non vengono utilizzate da VIO o duplicate da altre risorse VIO. |
| rollback | True | Esegue il rollback automatico in caso di errore (se possibile). |
| nsxv_token_lifetime | 1440 | Durata in minuti del token per l'accesso NSX-V. Il token viene fornito per NSX-T. La durata deve essere scelta in base alle dimensioni della distribuzione e al tempo previsto per il completamento della migrazione. Tale token non deve scadere prima del completamento della migrazione. |
| compute_clusters | Elenco di cluster di elaborazione vSphere che verranno migrati. Deve includere solo i cluster in cui vengono distribuite istanze di macchine virtuali VIO. I cluster Edge e i cluster di gestione VIO non devono essere inclusi. | |
| nsx_manager_ips | IP o FQDN per NSX-T Manager. Se si utilizza un cluster di gestione, questo parametro può specificare un VIP o l'elenco di istanze di NSX Manager. Nel secondo caso, verrà utilizzato il bilanciamento del carico sul lato client quando si accede a NSX Manager. | |
| nsx_manager_user | admin | Utente per l'accesso a NSX Manager. L'autenticazione con le identità entità non è supportata da VIO. |
| nsx_manager_password | Password per l'accesso a NSX Manager. | |
| metadata_proxy | Identificatore del proxy dei metadati per la zona di disponibilità predefinita VIO. L'identificatore è l'ultimo segmento del percorso del criterio della risorsa. | |
| dhcp_profile | Identificatore del profilo DHCP per la zona di disponibilità predefinita VIO. | |
| default_tier0_router | Identificatore del gateway di livello 0 per la zona di disponibilità predefinita VIO. Verrà utilizzato per il traffico nord-sud dai router Neutron il cui gateway è la rete esterna predefinita. | |
| default_overlay_tz | Zona di trasporto overlay di NSX-T da utilizzare per la distribuzione VIO. | |
| default_vlan_tz | Zona di trasporto VLAN NSX-T per la zona di disponibilità predefinita. | |
| transit_network | 100.64.0.0/16 | CIDR per la rete di transito NSX-T. Modificare solo se è stato modificato rispetto all'impostazione predefinita di NSX-T. |
| external_networks_map | Elenco vuoto | |
| availability_zones | Elenco vuoto |
Distribuzione dell'utilità di migrazione Neutron
./build_yaml.sh -t 7.1.1.1899999
| -k | Facoltativo. Non includere il certificato vCenter Server nella distribuzione. Specificare questo valore solo quando VIO utilizza una connessione vCenter non sicura. |
| -t <versione VIO completa> | Obbligatorio. La versione di VIO deve includere il numero di build e il tag di corrispondenza per le immagini VIO esistenti. |
Lo script build_yaml.sh crea <YAML-FILE-NAME> che contiene tutte le informazioni per la distribuzione del piano di controllo dell'utilità di migrazione Neutron.
Avvio della migrazione
kubectl apply -f <YAML-FILE-NAME>
Questa operazione creerà la distribuzione dell'utilità di migrazione Neutron nello spazio dei nomi OpenStack. Questa distribuzione ha una singola replica. Il pod della migrazione viene avviato automaticamente quando viene creato il pod della distribuzione.
Avvio del pod di migrazione
- Riproduzione API
- Avvio della migrazione da NSX Manager
- Riconfigurazione VIO
Il pod della migrazione terminerà se il file di configurazione non viene trovato o se non è stato specificato un parametro obbligatorio.
Inoltre, il pod della migrazione terminerà con un errore se lo stato corrente della migrazione è incoerente, ad esempio se la riproduzione dell'API non è stata completata, ma è già in corso una migrazione.
Quando viene avviato il processo di migrazione, i file di configurazione dei plug-in Neutron NSX vengono montati nel pod. Qualsiasi modifica apportata alla configurazione di Neutron in seguito all'avvio dell'utilità di migrazione non verrà elaborata dal processo di migrazione. Non è necessario apportare modifiche alla configurazione Neutron mentre l'utilità è in esecuzione. Se è necessario apportare modifiche, riavviare il processo di migrazione.
Riproduzione API
In questo stato il processo di migrazione creerà tutte le configurazioni necessarie in NSX-T e popolerà il database VIO Neutron per l'uso con NSX-T.
Al termine del processo, tutte le entità di rete logiche richieste da VIO verranno configurate in NSX-T, anche se i carichi di lavoro sono ancora in esecuzione in NSX-V.
- Controlli di preconvalida, ovvero i controlli elencati nella sezione Prerequisiti precedente.
- Controllo versione di NSX-T. La versione di NSX-T deve essere 3.2 o successiva.
- Verificare che sia configurato il gestore delle risorse di elaborazione. La migrazione richiede che il vCenter di VIO sia registrato come gestore delle risorse di elaborazione in NSX-T. Questo controllo verifica che ciò sia stato fatto.
- Nessuna risorsa Neutron deve essere configurata in NSX-T. Se l'opzione di rollback è impostata su True, il processo di allocazione pulirà qualsiasi risorsa Neutron (probabilmente obsoleta) trovata in NSX-T.
Una volta completati i controlli, il processo di migrazione inizializza il database Neutron NSX-T e ne prepara la struttura. Quindi, all'interno del pod dell'utilità di migrazione viene avviato un server Neutron. Questo server Neutron temporaneo è stato configurato per essere eseguito con NSX-T. Dopo che il server temporaneo è attivo, il processo di migrazione raccoglie informazioni sulle mappature di rete VNI e sulle mappature porta/VIF.
- Router (ai gateway di livello 1)
- Reti (ai segmenti)
- Subnet (alle subnet dei segmenti e alla configurazione DHCP dei segmenti)
- Porta (alle porte dei segmenti e ai binding statici DHCP)
- Gruppi di sicurezza (a criteri di protezione, regole, gruppi e servizi)
- IP mobili (alle regole NAT)
- Criteri e regole QoS
- Gruppi, criteri e regole FWaaS
- Bilanciamenti del carico, listener, pool, membri e monitor di integrità Octavia
Dopo aver completato la riproduzione API, il pod del server Neutron temporaneo viene arrestato.
Monitorare i registri dei pod dell'utilità di migrazione con il comando tail. Quando i registri mostrano che il pod dell'utilità di migrazione è in attesa di avviare il processo di migrazione NSX-T, eseguire l'attività successiva (migrazione completa dell'Edge).
Migrazione completa Edge
curl -v -s -X GET -k -u admin:<password> https://<nsx-mgr-ip>/api/v1/transport-nodes/ -H content-type:application/json
curl -v -s -X PUT -k -u admin:<password> https://<nsx-mgr-ip>/api/v1/transport-nodes/<edge-nodeid>/node/v2t-migration-config -H content-type:application/json -d '{"enabled": true}'
- Spegnerà le interfacce dell'appliance NSX-V Edge.
- Abiliterà ARP nel downlink NSX-T di livello 1 per garantire la fluida transizione del traffico est-ovest e nord-sud durante la migrazione.
- Si connetterà a vCenter per recuperare un token di autenticazione NSX-V.
- Preparerà un file di mappatura per i router distribuiti (NSX-V DLR).
- Configurerà la migrazione dell'Edge in NSX-T e ne attenderà il completamento.
Durante il cutover nord-sud, le macchine virtuali potrebbero perdere brevemente la connettività quando questa viene commutata dagli NSX-V ESG o DLR ai gateway di livello 1 di NSX-T. Al termine del cutover nord-sud, gli Edge NSX-V e dei metadati verranno disattivati. Il passaggio successivo è la migrazione dell'host.
IMPORTANTE: prima di avviare il cutover nord-sud, dopo un rollback, assicurarsi che sia presente il file di mappatura dell'Edge. Il file viene eliminato automaticamente dopo un rollback. Il processo dell'utilità di migrazione verrà ripristinato entro 10 secondi dal completamento di un rollback. Questa operazione non si applica se nell'ambiente VIO NSX-V non sono presenti router distribuiti.
Nota: il token di accesso NSX-V viene rinnovato a ogni esecuzione del pod. La sua durata deve essere sufficientemente lunga da garantire che la migrazione venga completata all'interno del ciclo di vita del pod dell'utilità di migrazione. Se il pod dell'utilità di migrazione viene riavviato per qualsiasi motivo, verrà recuperato un nuovo token.
Migrazione host
Seguire la procedura descritta in Migrazione di configurazione del firewall distribuito, host e carichi di lavoro.
- Disattiverà tutte le appliance NSX-V Edge.
- Configurerà la migrazione dell'host su NSX-T.
- Attenderà il completamento della migrazione dell'host.
Per garantire il corretto completamento della migrazione dell'host, è necessario spegnere le appliance dell'Edge. Non accendere le appliance di NSX-V Edge durante la migrazione dell'host.
curl -v -s -X PUT -k -u admin:<password> https://<nsx-mgr-ip>/api/v1/transport-nodes/<edge-nodeid>/node/v2t-migration-config -H content-type:application/json -d '{"enabled":false}'
Pulizia successiva alla migrazione
Il processo dell'utilità di migrazione riconfigura Neutron CR per l'utilizzo di NSX-T ma non rimuove i parametri di configurazione di NSX-V per consentirne la visualizzazione come riferimento. Questi parametri sono innocui. Una volta completata la migrazione, è possibile rimuoverli utilizzando il comando viocli update neutron.
Registrazione
Il processo di migrazione Neutron produce una registrazione dettagliata per ogni fase del processo. I registri scritti nello stdout del pod sono al livello INFO. I registri del livello di debug si trovano in /var/log/migration/vio-v2t.log nel nodo del controller VIO in cui viene eseguito il pod dell'utilità di migrazione.
osctl get pods neutron-migrator -o wide
È quindi possibile utilizzare il comando viossh per aprire una shell nel nodo del controller.
La directory /var/log/migration contiene anche il registro del server Neutron temporaneo.
Rollback
Il rollback può verificarsi in varie fasi durante la migrazione.
Se si verifica un errore durante la fase di riproduzione dell'API, non è necessario un rollback esplicito. L'utilità di migrazione Neutron VIO rimuoverà automaticamente le risorse create e riproverà la migrazione.
Se si sceglie di interrompere la migrazione eliminando il pod dell'utilità di migrazione Neutron, il piano di controllo VIO funzionerà ancora in NSX-V. Potrebbero essere presenti risorse di NSX-T create durante la riproduzione dell'API. Queste risorse verranno rimosse.
Tenere presente che NSX-T non consente il rollback della migrazione degli host. Dopo la migrazione degli host in NSX-T, non sarà possibile spostarli di nuovo in NSX-V.
Se durante la migrazione dell'host si verifica un errore, è possibile esaminare i registri e risolvere il problema nel modo appropriato.
In alternativa, se continua a verificarsi un errore di migrazione di un determinato host in NSX-T, è possibile rimuoverlo dal cluster vSphere e riprovare la migrazione. Le macchine virtuali in esecuzione sull'host in questione verranno migrate su altri host del cluster. Dopo la migrazione, installare NSX-T sull'host e aggiungerlo al cluster vSphere originale.
Codici di errore
| Codice | Descrizione |
|---|---|
| 0001, 0002, 0003, 0004 | Configurazione o stato del sistema non corretto. Durante la migrazione possono verificarsi problemi importanti, quali:
|
| 0101 | Non è possibile creare i file di configurazione per il server Neutron temporaneo, che deve essere attivo per la riproduzione dell'API. Controllare i registri pod del processo di migrazione oppure /var/log/migration/vio-v2t.log per eventuali errori. Questo errore può in genere essere eliminato risolvendo la causa principale con modifiche al file di configurazione. |
| 1001 | Il coordinatore della migrazione di NSX non è in esecuzione. Per risolvere questo errore, avviare il servizio coordinatore della migrazione sul primo nodo specificato in migrator.conf.json. Se si utilizza HA VIP, assicurarsi che l'istanza del gestore attivo sia quella in cui è in esecuzione il coordinatore della migrazione. Per la migrazione, è consigliabile utilizzare un NSX Manager specifico o utilizzare il bilanciamento del carico sul lato client. Gli FQDN di NSX-T Manager possono essere modificati dopo aver completato la migrazione. |
| 1002 | Versione di NSX-T non valida. È richiesto NSX 3.2.0 o versione successiva. |
| 1003 | Impossibile recuperare la versione di NSX-T. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. |
| 1004 | Errore durante la convalida del gestore delle risorse di elaborazione. Deve esistere almeno un gestore delle risorse di elaborazione definito in NSX-T. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. |
| 1005 | È necessario eseguire la pulizia in NSX-T. Nell'impostazione di NSX-T sono già presenti risorse create da VIO. Assicurarsi che rollback sia impostato su True in migrator.conf.json. |
| 1006 | Impossibile iniziare la migrazione di NSX-T. È probabile che questo sia il risultato di un precedente tentativo di migrazione. Eseguire il rollback di qualsiasi migrazione in corso e riprovare. |
| 1007 | Impossibile preparare NSX-T per il cutover nord-sud. Si è verificato un errore durante la configurazione del cutover nord-sud su NSX. Questo potrebbe essere un errore di generazione del file di mappature Edge o un errore verificatosi durante la preparazione del piano di migrazione. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. |
| 1008 | Il pod dell'utilità di migrazione non è in grado di disattivare le interfacce nelle appliance NSX-T Edge. Questo è un passaggio obbligatorio per il cutover nord-sud. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. Per risolvere il problema, impostare edge_migration_interfaces_down su False in migrator.conf.json e verificare manualmente che le interfacce dell'Edge siano inattive o disconnesse prima di avviare il cutover nord-sud. |
| 1009 | Impossibile eseguire la migrazione dei router senza downlink. Sono presenti router Neutron senza downlink. Questi non possono essere migrati. Se l'operatore ritiene che questo errore sia stato restituito per errore, è possibile ignorarlo impostando advanced_router_validation su False in migrator.conf.json. |
| 1100 | Modalità non valida nel piano di migrazione. Il coordinatore della migrazione NSX-T è già configurato con un piano diverso. È probabile che questo sia il risultato di un precedente tentativo di migrazione. Eseguire il rollback di qualsiasi migrazione in corso e riprovare. |
| 1101 | Migrazione di NSX-T non riconosciuta nella configurazione. Verificare che edge_migration e/o host_migration siano impostati su True ne file migration.conf.json. |
| 1105 | Impossibile applicare patch ai router senza gateway. Il processo per assicurarsi che i router Neutron senza gateway possano essere correttamente migrati a NSX-T non è riuscito. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. Impostando advanced_router_validation su False, questo processo verrà ignorato. Sarà tuttavia responsabilità dell'operatore assicurarsi che ogni gateway di livello 1 sia connesso a un router di livello 0 prima di avviare il cutover nord-sud in NSX-T. |
| 1106 | Impossibile ripristinare i router senza gateway. Il processo per il ripristino dei router Neutron senza gateway dopo il cutover nord-sud non è riuscito. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. Impostando advanced_router_validation su False questo processo verrà ignorato. Sarà tutto compito dell'operatore assicurarsi che i gateway di livello 1 siano disconnessi dal livello 0 per i router Neutron senza gateway. |
| 1110 | Impossibile avviare la migrazione nord-sud a NSX-T. Si è verificato un errore durante l'applicazione del piano di migrazione. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. |
| 1114 | Macchina virtuale mancante per le appliance Edge. Alcune appliance Edge non hanno un'appliance della macchina virtuale associata. Rimuovere il router Neutron corrispondente in modo che l'Edge venga rimosso. |
| 1115 | Impossibile spegnere le macchine virtuali NSX-V Edge prima di avviare la migrazione degli host. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. È possibile disattivare manualmente le macchine virtuali. Questa operazione è necessaria per evitare problemi durante la fase di runtime della migrazione dell'host. È necessario disattivare almeno DHCP e le appliance Edge del proxy dei metadati. |
| 1120 | Impossibile avviare la migrazione dell'host. Si è verificato un errore durante l'applicazione del piano di migrazione. Controllare i registri pod del processo i migrazione o /var/log/migration/vio-v2t.log per i dettagli dell'errore. |
| 1130, 1131 | Impossibile completare la migrazione. Errore durante l'impostazione della migrazione come completata. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. |
| 1132 | Timeout durante la migrazione. Il timeout per il cutover nord-sud è di 12 ore. Il timeout per la migrazione dell'host è di 48 ore. Se il pod del processo di migrazione viene lasciato in attesa dell'avvio di una migrazione, andrà in timeout. L'operatore dovrà semplicemente riavviarlo. |
| 2001 | Impossibile recuperare Neutron CR dal piano di controllo VIO. Potrebbe essersi verificato un problema di autorizzazione o un problema nel raggiungere il piano di controllo Kubernetes di VIO. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. |
| 2002 | Impossibile analizzare Neutron CR. Assicurarsi che nella sezione 'spec' sia presente un attributo 'manifests'. |
| 2003 | Contenuti non validi in Neutron CR. Verificare che il plug-in NSX-V sia abilitato e che tutti gli altri plug-in, incluso il plug-in NSX-T Policy, siano disabilitati. |
| 2004 | Impossibile aggiornare Neutron CR. Si è verificato un errore durante l'aggiornamento di Neutron CR. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. Questo potrebbe essere dovuto a un errore durante l'aggiornamento di Neutron CR, la creazione dell'istanza VIOSecret per la password di NSX-T o la creazione di risorse per gli NSX Manager. Verificare che queste risorse non siano rimaste obsolete in seguito a un precedente tentativo non riuscito. |
| 2011 | Si è verificato un errore durante la creazione di un database per NSX-T con criterio. È probabile che si tratti di un errore SQL. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. |
| 2012 | Si è verificato un errore durante la ridenominazione del database 'neutron_policy' in 'neutron'. È probabile che si tratti di un errore SQL. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. |
| 2111 | Impossibile avviare il server Neutron utilizzato per la riproduzione API. È probabile che si tratti di un errore di configurazione del server Neutron temporaneo. Controllare /var/log/neutron-server-tmp.log per eventuali errori. |
| 2112 | Riproduzione API non riuscita. Indica un errore durante la creazione delle risorse in NSX-T. Verificare la presenza di errori nei registri pod del processo di migrazione o in /var/log/migration/vio-v2t.log. I registri indicano quale risorsa non è stata creata. Controllare quindi /var/log/neutron-server-tmp.log per i dettagli relativi all'errore. Motivi di errore comuni:
|
