El asistente de migración de vRealize Automation 8 presenta estas limitaciones de implementación.
- La migración de una implementación es final, independientemente de si se realizó correctamente o no. No se puede volver a intentar una migración de implementación. Puede volver a ejecutar el plan creado mediante el servicio de migración en el servicio de incorporación. Cuando se vuelve a ejecutar con el servicio de incorporación, el propietario, la concesión y el historial de la implementación no se migran.
- La información de costes históricos no se migra con las implementaciones. Para obtener más información sobre los precios y los costes, consulte ¿Qué son las tarjetas de precios?
- Para implementaciones con redes a petición, si se migra una implementación que contiene una dirección IP administrada por IPAM y, a continuación, se elimina la implementación migrada de vRealize Automation 8, también se debe eliminar manualmente de Infoblox la dirección IP asociada.
- Después de migrar a vRealize Automation 8, se migra toda la información de IPAM. Sin embargo, las operaciones del día 2, como la eliminación de implementaciones, liberan las direcciones IP de un IPAM externo solo para implementaciones que contienen únicamente perfiles de red externa. Debe eliminar manualmente la dirección IP de IPAM para implementaciones que contengan redes a petición. Como solución alternativa, puede crear una suscripción para eliminar la IP de IPAM.
- Si el entorno de origen incluye un equilibrador de carga configurado en una red existente que no está conectada a una máquina, la red externa no se migrará y la IP no se asignará durante la migración.
- La funcionalidad "Actualizar implementación" solo funciona para implementaciones que contienen componentes de máquina de vSphere. Al ejecutar una acción de "Actualizar implementación" en implementaciones que contienen otros tipos de componentes (redes, máquinas de AWS, máquinas de Azure, etc.), se intenta volver a crear los componentes de la implementación.
- vRealize Automation 7 no recopila datos de los endpoints de Azure ni puede identificar si se eliminó una máquina de Azure fuera de vRealize Automation 7. Durante la evaluación de la migración en vRealize Automation 8, las implementaciones de Azure eliminadas aparecen como listas, pero se excluyen durante la migración, ya que el asistente de migración no puede encontrar las máquinas virtuales.
- No se puede migrar una implementación de origen si tiene tipos de red mixtos, como redes NAT/enrutadas en la misma implementación para NSX-T/NSX-V.
- No se migran las implementaciones de origen que contienen más de un componente de equilibrador de carga de NSX.
- Si su entorno de origen contiene varias implementaciones de un equilibrador de carga existente de ARM (equilibrador de carga a petición con red existente) creado a partir del mismo blueprint en NSX-T, el asistente de migración solo crea un equilibrador de carga. Solo se mostrará el componente de equilibrador de carga en una de las implementaciones migradas. Todas las demás implementaciones de equilibrador de carga de ARM existentes no tienen el componente de equilibrador de carga.
- La dirección IP configurada en la red NAT de las implementaciones de origen no se marca como asignada después de la migración. Sin embargo, las direcciones IP de los equilibradores de carga y las máquinas virtuales que se migraron se marcan como asignadas en después de la migración.
- Si la implementación de la instancia de origen de vRealize Automation 7 contiene un recurso no válido, por ejemplo, sin propiedades para un recurso, el recurso no se migra. Si ninguno de los recursos de la implementación es válido, no se migra la implementación completa.
- Durante la migración con infraestructura existente, ni las máquinas incorporadas ni las migradas se vinculan con zonas de nube. Como resultado, estas máquinas no se calculan en las definiciones de almacenamiento máximas.
- Si migra una implementación con un solo componente de máquina y un componente de red existente, vRealize Automation intenta volver a crear la máquina existente y genera el error "Se requiere subred".
- Si migra una implementación de vSphere vinculada a una plantilla de nube y, a continuación, actualiza la plantilla de nube después de la migración, se produce un error en la implementación.
- Si una implementación contiene reglas DNAT, las acciones del día 2 no se pueden volver a configurar después de la migración.
- Las máquinas agrupadas en clúster migradas no admiten el escalado vertical ni el escalado horizontal al aplicar actualizaciones iterativas de plantilla de nube a la implementación principal.
- Solo puede migrar implementaciones agrupadas en clúster desde entornos de origen de vRealize Automation 7.6. No se admite la migración de implementaciones agrupadas en clúster para entornos de origen de vRealize Automation 7.5, 7.4 o 7.3.
- Se produce un error en la migración si una implementación contiene 2 máquinas virtuales que están configuradas con el mismo perfil de red único, pero que pertenecen a redes diferentes. Antes de poder migrar esta implementación, debe actualizar las redes manualmente en vCenter cambiando el adaptador de red para que sea el mismo para ambas máquinas virtuales. Asegúrese de que la recopilación de datos se haya completado y de que las máquinas virtuales se hayan actualizado con las redes modificadas en las implementaciones de origen.
