Puede migrar la implementación de VMware Integrated OpenStack (VIO) de NSX-V a NSX. Durante la migración, el plano de control de VIO debe estar en modo de solo lectura.
La conectividad de la ruta de datos para las máquinas virtuales no se ve afectada durante la migración, excepto por breves interrupciones durante la transferencia norte-sur y la migración de hosts. Esta migración debe realizarse durante una única ventana de mantenimiento.
Descripción general del proceso de migración
- Instale NSX.
- Prepare NSX para VIO. Esto requiere configurar puertas de enlace de nivel 0 o VRF para redes externas, así como configurar clústeres de Edge, perfiles de servidor DHCP y proxies de metadatos. Para obtener más información, consulte https://docs.vmware.com/es/VMware-Integrated-OpenStack/index.html.
- Obtenga el paquete de migración de Neutron, que forma parte de los entregables de VIO.
- Configure el migrador de Neutron.
- Implemente el pod del migrador de Neutron.
- En la interfaz de usuario de NSX Manager:
- Inicie la transferencia de Edge.
- Controle los comentarios y complete la migración.
- Inicie la migración del host.
- Controle los comentarios y complete la migración.
- Espere a que se complete el pod del migrador de Neutron.
- Elimine la implementación del migrador de Neutron.
- Elimine la instalación de VIO en NSX-V.
Requisitos previos
- VIO 7.2.0 o una versión posterior
- NSX-V 6.4.11 o versiones posteriores
- vSphere 6.7 o una versión posterior (se recomienda actualizar los hosts ESXi a 7.0 o una versión posterior antes de la migración).
- Número de pares de direcciones permitidos en Neutron (el número de enlaces de direcciones manuales no debe superar los 128)
- Número de varias subredes con DHCP por conmutador lógico (solo se permite una en NSX)
- Número de vínculos superiores de enrutador por red (solo uno en NSX)
- Grupos de hosts: si está habilitado HA para los nodos de NSX Edge y se especifican grupos de hosts para los nodos de Edge que se colocarán. Esto generará una advertencia.
- HA se ignorará en NSX, ya que no se aplica. Esto generará una advertencia.
- Las redes de proveedor o las redes externas basadas en un grupo de puertos DVS no son compatibles con el complemento de NSX.
- No se admiten las redes VLAN con varios proveedores.
- Topologías de equilibrio de carga no compatibles con el complemento de NSX (por ejemplo, un equilibrador de carga con miembros de varias subredes no vinculadas al mismo enrutador de Edge o un equilibrador de carga en una red no conectada a un enrutador de Neutron).
- Uso de direcciones no válidas para NSX (por ejemplo, superposición con la red de tránsito).
- Máquinas virtuales implementadas en redes externas. No funcionan en NSX.
- Accesibilidad de subredes para miembros de equilibrio de carga. NSX requiere que todas las subredes del equilibrador de carga estén asociadas a la misma puerta de enlace.
En NSX, no debe haber ningún recurso que sea propiedad de OpenStack (por ejemplo, recursos de implementaciones de VIO anteriores en la instancia de NSX).
Consulte Migración local de partes específicas de NSX-V para ver los preparativos necesarios para la transferencia de Edge y la migración de hosts.
Preparación de la migración: dimensionar el clúster de NSX Edge
- Para cada VIP de OpenStack, busque la subred correspondiente y recupere el enrutador al que está vinculado, a menos que la subred esté en una red externa.
- Para cada grupo de LB de OpenStack, especifique los miembros. Busque la subred a la que pertenecen y recupere el enrutador al que está vinculada la subred.
La cantidad de enrutadores encontrados, junto con el tamaño del mayor LB de OpenStack, determinará la cantidad de ranuras de LB requeridas en el clúster de NSX Edge. Para cada LB, se requerirán dos ranuras para los enrutadores de servicio activo y en espera. Consulte https://configmax.vmware.com para conocer la cantidad máxima de equilibradores de carga que se pueden ejecutar en cada dispositivo de NSX Edge.
Preparación para la migración: configurar el grupo de direcciones IP de TEP
Durante la migración de hosts, los TEP de NSX-V y NSX deben poder comunicarse entre sí para garantizar la conectividad. Debe configurar el grupo de direcciones IP de los TEP de NSX para que pueda enrutar el tráfico a los TEP de NSX-V.
No se admiten los parámetros de configuración de NSX-V en NSX
En la siguiente tabla, se enumeran los parámetros de NSX-V no compatibles y los motivos.
Parámetro | Descripción | Motivo |
---|---|---|
cluster_moid | Especifica los identificadores de los clústeres utilizados por OpenStack. | No se aplica en NSX. |
datacenter_moid |
Identifica el centro de datos para implementar dispositivos Edge de NSX-V. | No se aplica en NSX. |
deployment_container_id |
Identifica el contenedor de implementación para las instancias de NSX-V Edge. | No se aplica en NSX. |
resource_pool_id |
Identifica el grupo de recursos para las instancias de NSX-V Edge. | No se aplica en NSX. |
datastore_id |
Identifica el almacén de datos de las instancias de NSX-V Edge. | No se aplica en NSX. |
ha_datastore_id |
Almacén de datos adicional si está habilitado HA de Edge. | No se aplica en NSX. |
ha_placement_random |
Divida las instancias de Edge activas entre el almacén de datos principal y secundario. | No se aplica en NSX. |
edge_host_groups |
Asegúrese de que las instancias de Edge activas/de copia de seguridad se coloquen en los grupos de hosts especificados. | No se aplica en NSX. |
external_network |
Identificador de DVPG que se utilizará para el vínculo superior de red física. | No se aplica en NSX. |
task_status_check_interval |
Intervalo para comprobar la finalización de la tarea. | No se aplica en NSX. |
vdn_scope_id |
Identificador del objeto de ámbito de red para los cables virtuales de VXLAN. | Los ámbitos de VDN se reemplazarán por zonas de transporte superpuestas de NSX. |
dvs_id |
Identificador de DVS conectado al clúster de administración y Edge. También se utiliza de forma predeterminada para las redes VLAN. | DVS se reemplaza por la zona de transporte de VLAN en NSX. |
maximum_tunnels_per_vnic |
Cantidad máxima de subinterfaces admitidas por una VNIC en un dispositivo Edge. | No se aplica en NSX. |
backup_edge_pool |
Define el tamaño del grupo perimetral de NSX-V que utilizará la implementación de OpenStack. | No se aplica en NSX. |
mgm_net_moid |
Identificador de grupo de puertos para la red de administración del proxy de metadatos. | No se aplica en NSX. |
mgt_net_proxy_ips |
Lista separada por comas de direcciones IP de la red de administración. | No se aplica en NSX. |
mgt_net_proxy_netmask |
Máscara de la red de administración para el proxy de metadatos. | No se aplica en NSX. |
mgt_net_default_gateway |
Puerta de enlace predeterminada de la red de administración para el proxy de metadatos. | No se aplica en NSX. |
nova_metadata_ips |
Direcciones IP utilizadas por el servicio de metadatos de Nova. | Se proporciona en la configuración de proxy de metadatos de NSX. |
nova_metadat_port |
Puerto utilizado por el servicio de metadatos de Nova. | Se proporciona en la configuración de proxy de metadatos de NSX. |
spoofguard_enabled |
De forma predeterminada, Spoofguard está habilitado en NSX-V, pero si deshabilita Spoofguard en NSX-V, Spoofguard se habilitará en NSX después de la migración. | Habilitado de forma predeterminada en NSX (no se puede desactivar globalmente). |
use_exclude_list |
Use el componente de lista de exclusión de NSX-V cuando la seguridad de puertos esté deshabilitada y Spoofguard esté habilitado. | Habilitado de forma predeterminada en NSX (no se puede desactivar globalmente). |
tenant_router_types |
Lista ordenada de tipos de enrutadores que se asignarán como enrutadores de tenant. | No se aplica en NSX. |
edge_appliance_user |
Nombre de usuario que se configurará para el inicio de sesión del dispositivo Edge. | No se aplica en NSX. |
metadata_initializer |
Inicializar infraestructura de acceso a metadatos | No se aplica en NSX. |
shared_router_appliance_size |
Tamaño del dispositivo de Edge que se utilizará para crear una instancia de Edge de enrutador compartido. | No se aplica en NSX. |
use_dvs_features |
Permita la configuración directa del respaldo de DVS de NSX-V. | No se aplica en NSX. |
service_insertion_profile_id |
El identificador de perfil de las reglas de firewall de redireccionamiento que se utilizará para la inserción de servicios. | La función no existe en la integración de NSX. |
service_insertion_redirect_all |
Crea una regla de firewall para redirigir todo el tráfico a un firewall de terceros. | La función no existe en la integración de NSX. |
use_nsx_policies |
Utilice directivas de NSX para implementar grupos de seguridad de Neutron. | La función no existe en la integración de NSX. |
default_policy_id |
Si use_nsx_policies es True , esta directiva se utilizará como directiva predeterminada para nuevos tenants |
La función no existe en la integración de NSX. |
bind_floatingip_to_all_interfaces |
Enlace las IP flotantes a las interfaces de vínculo inferior cuando esté configurada como True . |
En NSX, NAT para IP flotante siempre se procesará también para el tráfico este-oeste. |
vdr_transit_network |
Rango de redes para la conectividad TLR/PLR del enrutador distribuido. | En NSX, el rango de conectividad de DR/SR no se puede configurar desde OpenStack. |
exclusive_dhcp_edge |
Tener una instancia de Edge de DHCP exclusiva por red | No se aplica a NSX porque DHCP se implementa en el clúster de Edge. |
bgp_neighbour_hold_down_timer |
Intervalo para el tiempo de retención del vecino BGP. | La función no existe en la integración de NSX. El emparejamiento BGP se configura en la configuración de enrutamiento de puerta de enlace de nivel 0 de NSX. |
bgp_neighbour_keep_alive_timer |
Intervalo para el tiempo de conexión persistente del vecino. | La función no existe en la integración de NSX. El emparejamiento BGP se configura en la configuración de enrutamiento de puerta de enlace de nivel 0 de NSX. |
share_edges_between_tenants |
Utilice la misma instancia de Edge de enrutador o DHCP para varios tenants. | No se aplica en NSX. |
use_routers_as_lbaas_platform |
Utilice el enrutador exclusivo de la subred como plataforma para LBaaS. | No se aplica en NSX, donde los servicios de LB siempre se asocian a los contenedores utilizados para el reenvío. |
nsx_sg_name_format |
Formato del nombre NSX de un grupo de seguridad OpenStack. | La nomenclatura de recursos de back-end está implícita en NSX. |
loadbalancer_pool_transparency |
Cree grupos de LBaaS en modo transparente. | El modo transparente no se admite en NSX. |
default_edge_size |
Define el tamaño de Edge predeterminado para las instancias de Edge de enrutador, DHCP y LB. | No se aplica en NSX. |
Configurar el migrador de 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" }
Los parámetros de configuración son:
Parámetro | Valor predeterminado | Descripción |
---|---|---|
post_migration_cleanup | True | Una vez completada la migración, elimine las entidades de NSX adicionales creadas por el proceso de migración que no utilice VIO o que hayan duplicado otros recursos de VIO. |
rollback | True | Revierte automáticamente tras un error (si es posible). |
nsxv_token_lifetime | 1440 | Duración en minutos del token para el acceso a NSX-V. El token se proporciona a NSX. La duración debe elegirse según el tamaño y la hora de implementación esperados para completar la migración. El token no debe caducar antes de que se complete la migración. |
compute_clusters | Lista de clústeres de proceso de vSphere que se migrarán. Esto debe incluir solo los clústeres en los que se implementan instancias de máquina virtual de VIO. Los clústeres de Edge y los clústeres de administración de VIO no deben incluirse. | |
nsx_manager_ips | IP o FQDN para NSX Manager. Si se utiliza un clúster de Manager, este parámetro puede especificar una VIP o la lista de instancias de NSX Manager. En el último caso, se utilizará el equilibrio de carga del lado cliente al acceder a NSX Manager. | |
nsx_manager_user | admin | Usuario para acceso a NSX Manager. VIO no admite la autenticación con identidades de entidades de seguridad. |
nsx_manager_password | Contraseña para el acceso de NSX Manager. | |
metadata_proxy | Identificador del proxy de metadatos para la zona de disponibilidad predeterminada de VIO. El identificador es el último segmento de la ruta de directiva del recurso. | |
dhcp_profile | Identificador del perfil de DHCP para la zona de disponibilidad predeterminada de VIO. | |
default_tier0_router | Identificador de la puerta de enlace de nivel 0 para la zona de disponibilidad predeterminada de VIO. Lo usarán los enrutadores de Neutron cuya puerta de enlace es la red externa predeterminada para el tráfico norte-sur. | |
default_overlay_tz | Superposición de la zona de transporte de NSX que se utilizará para la implementación de VIO. | |
default_vlan_tz | Zona de transporte de NSX de VLAN para la zona de disponibilidad predeterminada. | |
transit_network | 100.64.0.0/16 | CIDR para la red de tránsito de NSX. Modifique solo si se cambió del valor predeterminado de NSX. |
external_networks_map | Lista vacía | |
availability_zones | Lista vacía |
Implementación de Neutron Migrator
./build_yaml.sh -t 7.1.1.1899999
-k | Opcional. No incluya el certificado de vCenter Server en la implementación. Especifique esto solo cuando VIO utilice una conexión de vCenter no segura. |
-t <versión completa de VIO> | Requerido. La versión de VIO debe incluir el número de compilación y la etiqueta de coincidencia para las imágenes de VIO existentes. |
El script build_yaml.sh crea <NOMBRE-ARCHIVO-YAML>, que contiene toda la información para implementar el plano de control de migración de Neutron.
Iniciando la migración
kubectl apply -f <YAML-FILE-NAME>
Esto creará la implementación neutron-migrator en el espacio de nombres de OpenStack. Esta implementación tiene una sola réplica. El pod de migración se inicia automáticamente cuando se crea el pod de la implementación.
Inicio del pod de migración
- Reproducción de API
- Iniciando migración desde NSX Manager
- Reconfiguración de VIO
El pod de migración finalizará si no se encuentra el archivo de configuración o si no se especificó algún parámetro obligatorio.
El pod de migración también finalizará con un error si el estado actual de la migración es incoherente, por ejemplo, si no se completó la reproducción de la API, pero ya hay una migración en curso.
Cuando se inicia el trabajo migrador, Los archivos de configuración de los complementos de NSX de Neutron se montarán en el pod. El trabajo migrador no procesará los cambios realizados en la configuración de Neutron una vez iniciado el migrador. No debe realizar cambios en la configuración de Neutron mientras se ejecuta el migrador. Si necesita realizar cambios, se debe reiniciar el trabajo migrador.
Reproducción de API
En este estado, el proceso de migración creará todas las configuraciones necesarias en NSX y rellenará la base de datos de VIO Neutron para usarla con NSX.
Al final de este proceso, todas las entidades de redes lógicas requeridas por VIO se configurarán en NSX, aunque las cargas de trabajo aún se ejecuten en NSX-V.
- Comprobaciones previas a la validación. Estas son las comprobaciones especificadas en la sección Requisitos previos anterior.
- Comprobación de versión de NSX. La versión de NSX debe ser 3.2 o posterior.
- Asegúrese de que se haya configurado el administrador de equipos. La migración requiere que la instancia de vCenter de VIO se registre como administrador de equipos en NSX. Esta comprobación verifica que se ha hecho así.
- No se debe configurar ningún recurso de Neutron en NSX. Si la opción de reversión se establece en True, el proceso migrador limpiará cualquier recurso de Neutron (probablemente obsoleto) que se encuentre en NSX.
Una vez completadas las comprobaciones, el proceso de migración inicializará la base de datos de NSX de Neutron y preparará su estructura. A continuación, se iniciará un servidor de Neutron temporal dentro del pod migrador. Este servidor Neutron temporal se configuró para ejecutarse con NSX. Una vez que el servidor Neutron temporal está activo, el proceso de migración recopilará información sobre las asignaciones de VNI de red y las asignaciones de puerto/VIF.
- Enrutadores (a puertas de enlace de nivel 1)
- Redes (a segmentos)
- Subredes (para la configuración de DHCP de subredes de segmentos y segmentos)
- Puerto (a puertos de segmentos y enlaces estáticos de DHCP)
- Grupos de seguridad (para directivas de seguridad, reglas, grupos y servicios)
- Direcciones IP flotantes (a reglas NAT)
- Directivas y reglas de QoS
- Reglas, directivas y grupos de FWaaS
- Equilibradores de carga, agentes de escucha, grupos, miembros y monitores de estado de Octavia
Una vez completada la reproducción de la API, el pod del servidor de Neutron temporal se apagará.
Supervise los registros del pod migrador con el comando tail. Cuando los registros muestran que el pod migrador está esperando a que se inicie el proceso de migración NSX, realice la siguiente tarea (Transferencia de Edge).
Transferencia de 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}'
- Desactive las interfaces del dispositivo de Edge de NSX-V.
- Habilite ARP en el vínculo inferior de nivel 1 de NSX para garantizar la transición sin problemas del tráfico este-oeste y norte-sur durante la migración.
- Conéctese a vCenter para recuperar un token de autenticación NSX-V.
- Prepare un archivo de asignación para enrutadores distribuidos (DLR de NSX-V).
- Configure la migración de Edge en NSX y espere a que finalice.
En la transferencia norte-sur, es posible que las máquinas virtuales pierdan conectividad brevemente , ya que la conectividad cambia de las ESG o los DLR de NSX V a las puertas de enlace de nivel 1 de NSX. Una vez completada la transferencia norte-sur, se apagarán las instancias de NSX-V y NSX-V. El siguiente paso es la migración de hosts.
IMPORTANTE: Antes de iniciar la transferencia norte-sur, después de una reversión, asegúrese de que el archivo de asignación de Edge esté presente. El archivo se elimina automáticamente después de una reversión. El trabajo migrador lo restaurará en los 10 segundos siguientes a la finalización de una reversión. Esto no se aplica si no hay enrutadores distribuidos en el entorno de VIO de NSX-V.
Nota: El token de acceso de NSX-V se renovará en cada ejecución del pod. Su duración debe ser lo suficientemente larga para garantizar que la migración se complete dentro del ciclo de vida del pod migrador. Si el pod migrador se reinicia por algún motivo, se recuperará un nuevo token.
Migración de hosts
Siga el procedimiento descrito en Migrar la configuración de firewall distribuido, hosts y cargas de trabajo.
- Apagar todos los dispositivos NSX-V Edge.
- Configurar la migración de hosts en NSX.
- Esperar a que la migración del host se complete correctamente.
Es necesario apagar los dispositivos de Edge para garantizar que la migración de hosts se complete correctamente. No encienda los dispositivos de NSX-V Edge durante la migración de hosts.
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}'
Limpieza posterior a la migración
El trabajo migrador vuelve a configurar el CR de Neutron para que use NSX, pero no eliminará los parámetros de configuración de NSX-V para que pueda verlos como referencia. Estos parámetros son inofensivos. Una vez completada la migración, podrá quitarlos mediante el comando viocli update neutron.
Registro
El proceso migrador de Neutron genera registros detallados para cada fase del proceso. Los registros escritos en el stdout del pod están en el nivel INFO. Los registros de nivel de depuración se encuentran en /var/log/migration/vio-v2t.log en el nodo del controlador de VIO donde se ejecuta el pod migrador.
osctl get pods neutron-migrator -o wide
A continuación, puede utilizar el comando viossh para abrir un shell en el nodo del controlador.
El directorio /var/log/migration también contiene el registro temporal del servidor Neutron.
Revertir
La reversión puede realizarse en varias etapas durante la migración.
Si se produce un error durante la etapa de reproducción de la API, no será necesario realizar una reversión explícita. La utilidad de migración Neutron de VIO eliminará automáticamente los recursos que se crearon y, a continuación, volverá a intentar la migración.
Si decide interrumpir la migración destruyendo el pod migrador de Neutron, el plano de control de VIO seguirá funcionando en NSX-V. Es posible que haya recursos de NSX creados por la reproducción de API. Estos recursos se eliminarán.
Tenga en cuenta que NSX no permite revertir la migración de hosts. Una vez que los hosts se hayan migrado a NSX, no será posible moverlos de nuevo a NSX-V.
Si se produce un error durante la migración del host, puede revisar los registros y solucionar el problema según corresponda.
De forma alternativa, si un host no puede migrar de forma coherente a NSX, puede quitarlo del clúster de vSphere y volver a intentar la migración. Las máquinas virtuales que se ejecuten en el host afectado se migrarán a otros hosts del clúster. Después de la migración, instale NSX en el host y agréguelo al clúster de vSphere original.
Códigos de error
Código | Descripción |
---|---|
0001, 0002, 0003, 0004 | Configuración o estado del sistema incorrectos. Existen problemas importantes con la migración, como los siguientes:
|
0101 | No se pueden crear archivos de configuración para el servidor de Neutron temporal, que debe estar activo para la reproducción de la API. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. Por lo general, este error se puede solucionar abordando la causa principal con cambios en el archivo de configuración. |
1001 | El coordinador de migración de NSX no se está ejecutando. Para solucionar este error, inicie el servicio del coordinador de migración en el primer nodo especificado en migrator.conf.json. Si utiliza la VIP de alta disponibilidad, asegúrese de que la instancia activa de Manager sea la instancia en la que se ejecuta el coordinador de migración. Para la migración, se recomienda utilizar una instancia de NSX Manager específica o el equilibrio de carga del lado del cliente. Los FQDN de NSX Manager se pueden cambiar una vez finalizada la migración. |
1002 | Versión de NSX no válida. Se requiere NSX 3.2.0 o una versión posterior. |
1003 | No se puede recuperar la versión de NSX. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. |
1004 | Error en la validación del administrador de equipos. Debe haber al menos un administrador de equipo definido en NSX. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. |
1005 | Debe ejecutar la limpieza en NSX. La configuración de NSX ya tiene recursos creados por VIO. Asegúrese de que rollback esté establecido en True en migrator.conf.json. |
1006 | No se puede iniciar la migración de NSX. Esto probablemente sea el resultado de un intento de migración anterior. Revierta cualquier migración en curso y vuelva a intentarlo. |
1007 | No se puede preparar NSX para la transferencia norte-sur. Se produjo un error al configurar la transferencia norte-sur en NSX. Esto puede ser un error al generar el archivo de "asignaciones de Edge" o un error al preparar el plan de migración. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. |
1008 | El pod migrador no puede desactivar interfaces en los dispositivos de NSXEdge. Este paso es obligatorio para la transferencia norte-sur. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. Para solucionar este problema, establezca edge_migration_interfaces_down en False en migrator.conf.json y asegúrese manualmente de que las interfaces de Edge estén inactivas o desconectadas antes de iniciar la transferencia norte-sur. |
1009 | No se pueden migrar enrutadores sin vínculos inferiores. Hay un enrutador de Neutron sin vínculos inferiores. No se pueden migrar. Si el operador cree que este error se produce sin motivo, se puede omitir estableciendo advanced_router_validation en False en migrator.conf.json. |
1100 | Modo no válido en el plan de migración. El coordinador de migración de NSX ya está configurado con un plan diferente. Esto probablemente sea el resultado de un intento de migración anterior. Revierta cualquier migración en curso y vuelva a intentarlo. |
1101 | Migración de NSX no confirmada en la configuración. Asegúrese de que edge_migration o host_migration estén establecidos en True en migration.conf.json. |
1105 | No se pueden aplicar revisiones a enrutadores sin puerta de enlace. Se produjo un error en el proceso para garantizar que los enrutadores de Neutron sin puerta de enlace se puedan migrar sin problemas a NSX. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. Al establecer advanced_router_validation en False, se omitirá este proceso. Sin embargo, dependerá del operador para garantizar que cada puerta de enlace de nivel 1 esté conectada a un enrutador de nivel 0 antes de iniciar la transferencia norte-sur en NSX. |
1106 | No se pueden restaurar enrutadores sin puerta de enlace. Se produjo un error en el proceso para restaurar los enrutadores de Neutron sin puerta de enlace después de la transferencia norte-sur. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. Al configurar advanced_router_validation en False se omitirá este proceso. Sin embargo, será el operador el que se asegure de que las puertas de enlace de nivel 1 estén desconectadas del nivel 0 para los enrutadores de Neutron sin puertas de enlace. |
1110 | No se puede iniciar la migración total norte-sur a NSX. Se produjo un error al aplicar el plan de migración. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. |
1114 | Falta la máquina virtual para los dispositivos de Edge. Algunos dispositivos de Edge no tienen un dispositivo de máquina virtual asociado. Elimine el enrutador de Neutron correspondiente para que se elimine la instancia de Edge. |
1115 | No se pueden apagar las máquinas virtuales de NSX-V Edge antes de iniciar la migración de hosts. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. Considere apagar las máquinas virtuales de forma manual. Esto es necesario para evitar problemas durante la fase de tiempo de ejecución de la migración del host. Debe apagar al menos los dispositivos de Edge proxy de metadatos y DHCP. |
1120 | No se puede iniciar la migración de hosts. Se produjo un error al aplicar el plan de migración. Compruebe los detalles de los errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. |
1130, 1131 | No se puede completar la migración. Error al configurar la migración como finalizada. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. |
1132 | Se agotó el tiempo de espera durante la migración. El tiempo de espera para la transferencia norte-sur es de 12 horas. El tiempo de espera para la migración de hosts es de 48 horas. Si el pod de trabajo del migrador se queda a la espera de que se inicie una migración, se agotará el tiempo de espera. El operador solo necesitará reiniciarlo. |
2001 | No se puede recuperar el CR de Neutron del plano de control de VIO. Esto puede ser un problema de autorización o un problema al alcanzar el plano de control de Kubernetes de VIO. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. |
2002 | No se puede analizar el CR de Neutron. Asegúrese de que haya un atributo 'manifests' en la sección 'spec'. |
2003 | Contenido no válido en CR de Neutron. Asegúrese de que el complemento de NSX-V esté habilitado, así como también los demás complementos, incluido el complemento de Directiva de NSX. |
2004 | No se puede actualizar el CR de Neutron. Se produjo un error al actualizar el CR de Neutron. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. Esto podría ser un error al actualizar el CR de Neutron, al crear la instancia de VIOSecret para la contraseña de NSX o al crear recursos para las instancias de NSX Manager. Compruebe que estos recursos no se hayan quedado obsoletos de algún intento fallido anterior. |
2011 | Se produjo un error al crear una base de datos para NSX con directiva. Es probable que se trate de un error SQL. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. |
2012 | Se produjo un error al cambiar el nombre de la base de datos 'neutron_policy' a 'neutron'. Es probable que se trate de un error de SQL. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. |
2111 | No se pudo iniciar el servidor neutron temporal utilizado para la reproducción de API. Es probable que se deba a un error en la configuración del servidor de Neutron temporal. Compruebe si hay errores en /var/log/neutron-server-tmp.log. |
2112 | Error de reproducción de API. Esto indica un error al crear recursos en NSX. Compruebe si hay errores en los registros del pod del trabajo migrador o en /var/log/migration/vio-v2t.log. Los registros mostrarán qué recurso no se pudo crear. A continuación, compruebe los detalles del error en /var/log/neutron-server-tmp.log. Motivos comunes de error:
|