Puede migrar la implementación de VMware Integrated OpenStack (VIO) de NSX-V a NSX-T. 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

  1. Instale NSX-T.
  2. Prepare NSX-T 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.
  3. Obtenga el paquete de migración de Neutron, que forma parte de los entregables de VIO.
  4. Configure el migrador de Neutron.
  5. Implemente el pod del migrador de Neutron.
  6. 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.
  7. Espere a que se complete el pod del migrador de Neutron.
  8. Elimine la implementación del migrador de Neutron.
  9. 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).
El pod del migrador de Neutron ejecutará las siguientes comprobaciones de validación. Las comprobaciones que producen una advertencia se pueden omitir a través de la configuración del migrador de Neutron.
  • 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-T)
  • Número de vínculos superiores de enrutador por red (solo uno en NSX-T)
  • 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-T, 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-T.
  • No se admiten las redes VLAN con varios proveedores.
  • Topologías de equilibrio de carga no compatibles con el complemento de NSX-T (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-T (por ejemplo, superposición con la red de tránsito).
  • Máquinas virtuales implementadas en redes externas. No funcionan en NSX-T.
  • Accesibilidad de subredes para miembros de equilibrio de carga. NSX-T requiere que todas las subredes del equilibrador de carga estén asociadas a la misma puerta de enlace.

En NSX-T, no debe haber ningún recurso que sea propiedad de OpenStack (por ejemplo, recursos de implementaciones de VIO anteriores en la instancia de NSX-T).

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-T Edge

El clúster de NSX-T Edge debe tener suficientes ranuras para equilibradores de carga (LB) de OpenStack. Para determinar la lista de puertas de enlace de nivel 1 que alojarán un servicio de LB, haga lo siguiente:
  • 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-T 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-T 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-T deben poder comunicarse entre sí para garantizar la conectividad. Debe configurar el grupo de direcciones IP de los TEP de NSX-T 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-T

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-T.

datacenter_moid

Identifica el centro de datos para implementar dispositivos Edge de NSX-V. No se aplica en NSX-T.

deployment_container_id

Identifica el contenedor de implementación para las instancias de NSX-V Edge. No se aplica en NSX-T.

resource_pool_id

Identifica el grupo de recursos para las instancias de NSX-V Edge. No se aplica en NSX-T.

datastore_id

Identifica el almacén de datos de las instancias de NSX-V Edge. No se aplica en NSX-T.

ha_datastore_id

Almacén de datos adicional si está habilitado HA de Edge. No se aplica en NSX-T.

ha_placement_random

Divida las instancias de Edge activas entre el almacén de datos principal y secundario. No se aplica en NSX-T.

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-T.

external_network

Identificador de DVPG que se utilizará para el vínculo superior de red física. No se aplica en NSX-T.

task_status_check_interval

Intervalo para comprobar la finalización de la tarea. No se aplica en NSX-T.

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-T.

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-T.

maximum_tunnels_per_vnic

Cantidad máxima de subinterfaces admitidas por una VNIC en un dispositivo Edge. No se aplica en NSX-T.

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-T.

mgm_net_moid

Identificador de grupo de puertos para la red de administración del proxy de metadatos. No se aplica en NSX-T.

mgt_net_proxy_ips

Lista separada por comas de direcciones IP de la red de administración. No se aplica en NSX-T.

mgt_net_proxy_netmask

Máscara de la red de administración para el proxy de metadatos. No se aplica en NSX-T.

mgt_net_default_gateway

Puerta de enlace predeterminada de la red de administración para el proxy de metadatos. No se aplica en NSX-T.

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-T.

nova_metadat_port

Puerto utilizado por el servicio de metadatos de Nova. Se proporciona en la configuración de proxy de metadatos de NSX-T.

spoofguard_enabled

De forma predeterminada, Spoofguard está habilitado en NSX-V, pero si deshabilita Spoofguard en NSX-V, Spoofguard se habilitará en NSX-T después de la migración. Habilitado de forma predeterminada en NSX-T (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-T (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-T.

edge_appliance_user

Nombre de usuario que se configurará para el inicio de sesión del dispositivo Edge. No se aplica en NSX-T.

metadata_initializer

Inicializar infraestructura de acceso a metadatos No se aplica en NSX-T.

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-T.

use_dvs_features

Permita la configuración directa del respaldo de DVS de NSX-V. No se aplica en NSX-T.

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-T.

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-T.

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-T.

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-T.

bind_floatingip_to_all_interfaces

Enlace las IP flotantes a las interfaces de vínculo inferior cuando esté configurada como True. En NSX-T, 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-T, 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-T 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-T. 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-T. 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-T.

use_routers_as_lbaas_platform

Utilice el enrutador exclusivo de la subred como plataforma para LBaaS. No se aplica en NSX-T, 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-T.

loadbalancer_pool_transparency

Cree grupos de LBaaS en modo transparente. El modo transparente no se admite en NSX-T.

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-T.

Configurar el migrador de Neutron

Antes de iniciar el migrador de Neutron, cree un archivo JSON denominado migrator.conf.json para especificar el entorno de NSX-T y los hosts que se deben migrar. Este archivo se montará en el pod migrador y se validará mediante el proceso de migración. El siguiente es un archivo migrator.conf.json de ejemplo:
{
 "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-T 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-T. 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-T 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-T que se utilizará para la implementación de VIO.
default_vlan_tz Zona de transporte de NSX-T de VLAN para la zona de disponibilidad predeterminada.
transit_network 100.64.0.0/16 CIDR para la red de tránsito de NSX-T. Modifique solo si se cambió del valor predeterminado de NSX-T.
external_networks_map Lista vacía
availability_zones Lista vacía

Implementación de Neutron Migrator

En el paquete migrador hay un script llamado build_yaml.sh. Cuando la configuración del migrador esté lista, ejecute el script para crear la especificación de implementación e implementarla en el plano de control de VIO. Por ejemplo:
./build_yaml.sh -t 7.1.1.1899999
El script acepta los siguientes parámetros:
-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

Para iniciar la migración, ejecute el siguiente comando:
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

Durante el inicio, el pod migrador leerá el archivo de configuración y el estado actual de la migración. En función de esta información, decidirá el siguiente paso de la migración, que podría ser uno de los siguientes:
  • 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-T y rellenará la base de datos de VIO Neutron para usarla con NSX-T.

Al final de este proceso, todas las entidades de redes lógicas requeridas por VIO se configurarán en NSX-T, aunque las cargas de trabajo aún se ejecuten en NSX-V.

Antes de implementar la configuración de VIO en NSX-T, se realizan las siguientes comprobaciones:
  • Comprobaciones previas a la validación. Estas son las comprobaciones especificadas en la sección Requisitos previos anterior.
  • Comprobación de la versión de NSX-T. La versión de NSX-T 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-T. Esta comprobación verifica que se haya hecho.
  • No se debe configurar ningún recurso de Neutron en NSX-T. 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-T.

Una vez completadas las comprobaciones, el proceso de migración inicializará la base de datos de NSX-T 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-T. 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.

A continuación, se iniciará el proceso de migración de API y se migrarán los siguientes recursos:
  • 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-T, realice la siguiente tarea (Transferencia de Edge).

Transferencia de Edge

Siga el procedimiento descrito en Migrar tráfico de norte a sur a instancias de NSX-T Edge mediante la migración total de Edge. Después de esta migración, NSX-T controlará el tráfico norte-sur. El proceso de migración realizará lo siguiente:
  • Desactive las interfaces del dispositivo de Edge de NSX-V.
  • Habilite ARP en el vínculo inferior de nivel 1 de NSX-T 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-T 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-T. 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.

INPORTANTE: 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.

La utilidad de migración de VIO hará lo siguiente:
  • Apagar todos los dispositivos NSX-V Edge.
  • Configurar la migración de hosts en NSX-T.
  • 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.

Limpieza posterior a la migración

El trabajo migrador vuelve a configurar el CR de Neutron para que use NSX-T, 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.

Puede averiguar en qué nodo se ejecuta el pod migrador de Neutron con el siguiente comando:
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-T creados por la reproducción de API. Estos recursos se eliminarán.

Tenga en cuenta que NSX-T no permite revertir la migración de hosts. Una vez que los hosts se hayan migrado a NSX-T, 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-T, 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-T 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:
  • La migración del host ya se completó, pero no se realizó la reproducción de la API.
  • VIO ya se está ejecutando con NSX-T, pero no se realizó la reproducción o la migración de la API.
  • Los hosts están en NSX-T, VIO se está ejecutando con NSX-T, pero no se realizó la reproducción de la API.
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-T Manager se pueden cambiar una vez finalizada la migración.
1002 Versión de NSX-T no válida. Se requiere NSX 3.2.0 o una versión posterior.
1003 No se puede recuperar la versión de NSX-T. 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 equipos definido en NSX-T. 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-T. La configuración de NSX-T 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-T. 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-T 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 NSX-T Edge. 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-T 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-T 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-T. 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-T.
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 transferencia norte-sur a NSX-T. 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-T.
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-T 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-T 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-T. 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:
  • Zonas de transporte incorrectas en la configuración temporal del servidor neutron
  • Redes que no son de OpenStack que usan la misma VLAN que alguna red de OpenStack
  • El clúster de Edge se está quedando sin ranuras para los equilibradores de carga