La información de esta sección puede resultar útil para solucionar problemas durante la migración.

Problemas de configuración de importación

Problema Solución
La configuración de importación falla. Haga clic en Reintentar para intentar volver a importar. Solo los pasos de importación con errores se reintentan.

Problemas de migración de host

Problema Solución
Se produce un error en la migración del host debido a que falta un parámetro de configuración del administrador de equipos.

La configuración del administrador de equipos es un requisito previo para la migración. Sin embargo, si la configuración del administrador de equipos se elimina de la instancia de NSX Manager una vez iniciada la migración, el coordinador de migración conserva la configuración. La migración continúa hasta el paso de migración de host, en el que se produce un error.

Agregue un administrador de equipos a NSX Manager e introduzca los mismos detalles de vCenter Server que se utilizaron para la importación de la configuración de NSX-V inicial.

Se produce un error en la migración del host debido a que existen dvFilters obsoletos.

Ejemplo de mensaje de error: Stale dvFilters present: ['port 33554463 (disconnected)', 'port 33554464 (disconnected)'] Stale dvfilters present. Aborting ]

Inicie sesión en el host que no se pudo migrar, identifique los puertos desconectados y reinicie la máquina virtual correspondiente o conecte los puertos desconectados. A continuación, vuelva a intentar el paso de migración de host.

  1. Inicie sesión en la interfaz de línea de comandos del host que no se pudo migrar.
  2. Ejecute summarize-dvfilter y busque los puertos mencionados en el mensaje de error. 
    world 1000057161 vmm0:2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745 vcUuid:'96 3a dc b8 ab 56 41 d6-bd 9e 2d 1c 32 9e 77 45'
 port 33554463 (disconnected)
  vNic slot 2
  name: nic-1000057161-eth1-vmware-sfw.2
 agentName: vmware-sfw
   state: IOChain Detached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
  3. Busque la máquina virtual y el puerto afectados.
    Por ejemplo, el mensaje de error indica que el puerto 33554463 está desconectado.
    1. Busque la sección de la salida summarize-dvfilter que corresponde a este puerto. El nombre de la máquina virtual se muestra aquí. En este caso, es 2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745.
    2. Busque la entrada name para determinar qué interfaz de la máquina virtual está desconectada. En este caso, es eth1. Por lo tanto, la segunda interfaz de 2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745 está desconectada.
  4. Resuelva el problema con este puerto. Lleve a cabo uno de los siguientes pasos:
    • Reinicie la máquina virtual afectada.
    • Conecte el puerto de vnic desconectado a cualquier red.
  5. En la página Migrar hosts, haga clic en Reintentar.

Después de migrar hosts mediante vMotion, es posible que las máquinas virtuales experimenten una interrupción del tráfico si SpoofGuard está habilitado en NSX-V.

Síntomas:

El archivo vmkernel.log en el host ubicado en /var/run/log/ muestra una caída del tráfico debido a SpoofGuard.

Por ejemplo, el archivo de registro muestra: WARNING: swsec.throttle: SpoofGuardMatchWL:296:[nsx@6876 comp="nsx-esx" subcomp="swsec"]Filter 0x8000012 [P]DROP sgType 4 vlan 0 mac 00:50:56:84:ee:db

Motivo:

El conmutador lógico y la configuración del puerto del conmutador lógico se migran a través del coordinador de migración, que migra la configuración de SpoofGuard. Sin embargo, los enlaces de puertos detectados no se migran a través de vMotion. Por lo tanto, SpoofGuard descarta los paquetes.
Si SpoofGuard está habilitado en NSX-V antes de la migración, aplique una de estas soluciones alternativas después de mover las máquinas virtuales con vMotion:
  • Deshabilite las directivas de SpoofGuard.
  • Agregue los enlaces de direcciones IP y MAC del puerto como enlaces manuales.
  • Si la intromisión de ARP está habilitada, espere a que ARP obtenga las direcciones IP de la máquina virtual.

En las primeras dos opciones, el tráfico de red se restaura inmediatamente.

En la tercera opción:
  • El tiempo de inactividad del tráfico se observa hasta que la máquina virtual envía una respuesta o una solicitud de ARP.
  • Si la intromisión de DHCP también está habilitada y el servidor DHCP asignó la dirección IP de la máquina virtual, lo más probable es que se obtenga como ARP primero y más adelante como una dirección IP obtenida por DHCP.

En mitad de una migración de clúster, se produjo un error en la migración de host debido a un error de hardware en el host.

Por ejemplo, supongamos que un clúster tiene 10 hosts y que cuatro se migraron correctamente. El quinto host tiene un fallo de hardware y la migración del host falla.
Si no se puede solucionar el error de hardware del host, omita este host con errores en la migración y vuelva a intentar la migración de los hosts. Complete los siguientes pasos de solución alternativa:
  1. En la interfaz de usuario de vCenter Server, quite el host con errores del inventario.

    Espere unos minutos hasta que se elimine el host.

  2. Inicie sesión en el dispositivo de NSX Manager en el que se ejecuta el servicio del coordinador de migración y ejecute la siguiente solicitud de API:

    GET https://{nsxt-policy-ip}/api/v1/migration/migration-unit-groups?component_type=HOST&sync=true

  3. Vuelva a la interfaz de usuario de NSX Manager de NSX-T y actualice el navegador. Observe que el host con errores ya no está visible.
  4. Haga clic en Reintentar para continuar con la migración de los hosts.
Si necesita reiniciar el servicio del coordinador de migración por cualquier motivo, los clústeres que ya se hayan migrado a NSX-T volverán a estar disponibles para la migración en la página Migrar hosts. Este comportamiento es un problema conocido. En este caso, la solución alternativa será omitir los clústeres migrados siguiendo estos pasos:
  1. Abra una sesión de SSH en el dispositivo de NSX Manager de NSX-T en el que se ejecuta el servicio del coordinador de migración.
  2. Edite el archivo de /var/log/migration-coordinator/v2t/clusters-to-migrate.json para quitar los clústeres que ya se han migrado.

    Por ejemplo, si el archivo tiene el siguiente contenido y el clúster 1 se migró, elimine el elemento {"modId":"domain-c9", "name":"cluster-1"}.

    "clusters":[
   {
     "modId":"domain-c9",
     "name":"cluster-1"
   },
   {
     "modId":"domain-c19",
     "name":"cluster-2"
   }
 ]
  3. Ejecute la misma solicitud de API en el dispositivo de NSX Manager especificado en la solución alternativa anterior.
  4. Vuelva a la interfaz de usuario de NSX Manager de NSX-T y actualice el navegador. Vaya a la página Migrar hosts y observe que los clústeres que quitó del archivo clusters-to-migrate.json aparecen como No migrar.
  5. Haga clic en Reintentar para continuar con la migración de los hosts.
La migración de hosts se bloque después de aceptar la recomendación porque la máquina virtual del controlador de NSX-V se encuentra en estado apagado. En el paso de migración de hosts, los comentarios recomiendan anular la migración. Si acepta la recomendación, se produce un error en la migración. Cuando se realiza la transferencia de Edge, puede cambiar la acción a skip y continuar con la migración siguiendo estos pasos:
  1. Realice la siguiente llamada API y busque el resultado de NoNsxvControllerInRunningSate para encontrar la solicitud de comentarios y obtener su identificador:
    GET https://$NSX_MANAGER_IP/api/v1/migration/feedack-requests?state=UNRESOLVED
  2. Acepte todas las recomendaciones realizando la siguiente llamada API:
    POST https://$NSX_MANAGER_IP/api/v1/migration/feedback-response?action=accept-recommended
  3. Proporcione una respuesta de comentarios con la acción skip con la siguiente llamada API (tenga en cuenta que $FEEDBACK_ID es el identificador que obtuvo en el paso 1):
    PUT https://$NSX_MANAGER_IP/api/v1/migration/feedback-response -d '{"response_list":[{"id": $FEEDBACK_ID, "action": "skip" }]}'

Revertir una migración

Problema Solución
En algunas implementaciones de OSPF de NSX-V, si realiza una reversión después de la fase de migración de Edge, es posible que vea el error "Motivo: NSCutover falló con '400: Error de configuración en NSX Edge VM vm-XXXX". Vuelva a implementar la máquina virtual de NSX-V Edge relevante. Una vez que la máquina virtual se vuelva a implementar correctamente, repita la reversión.

Reintentar una migración

Problema Solución
Si un host se reinicia por algún motivo durante una migración, se produce un error al reintentar la migración, como "No se encontró el objeto solicitado: TransportNode/42178ba8-49fb-9545-2b78-5e9c64fddda7. Los identificadores de objetos distinguen entre mayúsculas y minúsculas. Realice los pasos siguientes:
  1. En la interfaz de usuario de VC, quite el host de su clúster y conviértalo en un host independiente.
  2. En la interfaz de usuario de NSX Manager, configure NSX en el host independiente con el mismo VDS. Haga que el nodo de transporte se una a la misma superposición y a las mismas zonas de transporte de VLAN a las que se unen otros hosts migrados.
  3. Desde la interfaz de usuario de NSX Manager, vuelva a la pantalla de migración y actualícela para asegurarse de que el host no se encuentre en el clúster que se va a migrar. Vuelva a intentar la migración del clúster.
  4. Después de la migración, vuelva a agregar el host al clúster.

Eliminar datos de VTEP obsoletos

Problema Solución
Si la migración se cancela después de migrar las puertas de enlace de servicios Edge, es posible que haya tablas de VTEP obsoletas en NSX-T. Si hay nodos de transporte en NSX-T, su estado de túnel permanecerá inactivo para estos VTEP obsoletos. Para retirar los datos obsoletos de VTEP, realice la siguiente llamada API: 
GET https://<nsx-manager-IP>/api/v1/global-configs/SwitchingGlobalConfig
Si el parámetro global_replication_mode_enabled de la carga útil de resultados es true, tome esta carga útil, asigne el valor false a global_replication_mode_enabled y utilice la carga útil para realizar la siguiente llamada API: 
PUT https://<nsx-manager-IP>/api/v1/global-configs/SwitchingGlobalConfig
.

Problemas de migración del servicio de partners

Problema Solución

El coordinador de migración no muestra los mensajes de comentarios de la categoría de inserción de servicios en la página Resolver configuración a pesar de que las directivas de seguridad de su entorno de NSX-V contienen reglas de introspección de red.

Este problema se produce cuando se está migrando una combinación de servicios de introspección de red y de Guest Introspection desde el mismo partner. Si ya se ha creado un perfil de servicio para el servicio de partners en NSX-T, el coordinador de migración no iniciará la migración de las reglas de introspección de red.
Compruebe si ya se ha creado un perfil de servicio en el entorno de NSX-T. Si es así, siga estos pasos:
  1. Revierta la migración.
  2. Elimine el perfil de servicio de partners y la referencia de servicio en NSX-T.
  3. Reinicie la migración.

Problemas posteriores a la migración

Problema Solución

Después de una migración y después de eliminar las ESG de la red, NSX-T activa alarmas informando que los vecinos OSPF están inactivos para estas ESG. Si resuelven las alarmas, se volverán a activar.

Confirme las alarmas, pero no las resuelva. Esto evitará que se vuelvan a activar.