L'assistant de migration de vRealize Automation 8 présente ces limitations relatives aux déploiements.
- La migration d'un déploiement est définitive, qu'elle soit réussie ou non. Vous ne pouvez pas réessayer la migration d'un déploiement. Vous pouvez réexécuter le plan créé par le service de migration sous se service d'intégration. Lors d'une réexécution à l'aide du service d'intégration, le propriétaire, le bail et l'historique du déploiement ne sont pas migrés.
- L'historique des informations sur les coûts n'est pas migré avec les déploiements. Pour plus d'informations sur la tarification et les coûts, consultez Qu'entend-on par cartes de tarification.
- Pour les déploiements avec des réseaux à la demande, si vous migrez un déploiement qui contient une adresse IP gérée par IPAM et que vous supprimez le déploiement migré de vRealize Automation 8, vous devez également supprimer manuellement l'adresse IP associée d'Infoblox.
- Après la migration vers vRealize Automation 8, toutes les informations IPAM sont migrées. Cependant, les opérations de jour 2, telles que la suppression de déploiements, libèrent les adresses IP d'un IPAM externe pour les déploiements contenant uniquement des profils réseau externes. Vous devez supprimer manuellement l'adresse IP d'IPAM pour les déploiements contenant des réseaux à la demande. Pour contourner ce problème, vous pouvez créer un abonnement pour supprimer l'adresse IP d'IPAM.
- Si votre environnement source inclut un équilibrage de charge configuré sur un réseau existant qui n'est pas connecté à une machine, le réseau externe n'est pas migré et l'adresse IP n'est pas allouée pendant la migration.
- La fonctionnalité « Mettre à jour le déploiement » ne fonctionne que pour les déploiements contenant des composants de machine vSphere. L'exécution d'une action « Mettre à jour le déploiement » sur les déploiements contenant d'autres types de composants (réseaux, machines AWS, machines Azure, etc.) tente de recréer les composants de déploiement.
- vRealize Automation 7 ne collecte pas les données des points de terminaison Azure et ne peut pas déterminer si une machine Azure a été supprimée en dehors de vRealize Automation 7. Lors de l'évaluation de la migration dans vRealize Automation 8, les déploiements Azure supprimés sont répertoriés comme étant Prêts, mais sont exclus lors de la migration, car l'assistant de migration ne parvient pas à trouver les machines virtuelles.
- Vous ne pouvez pas migrer un déploiement source s'il dispose de types de réseaux mixtes, tels que des réseaux NAT/route dans le même déploiement pour NSX-T/NSX-V.
- Les déploiements source qui contiennent plusieurs composants NSX Load Balancer ne sont pas migrés.
- Si votre environnement source contient plusieurs déploiements d'un équilibrage de charge à un bras existant (équilibrage de charge à la demande avec réseau existant) créé à partir du même Blueprint sur NSX-T, l'assistant de migration ne crée qu'un seul équilibrage de charge. Le composant d'équilibrage de charge sera répertorié dans un seul des déploiements migrés. Tous les autres déploiements d'un équilibrage de charge à un bras ne disposent pas du composant d'équilibrage de charge.
- L'adresse IP configurée sur le réseau NAT dans vos déploiements source n'est pas marquée comme allouée après la migration. Cependant, les adresses IP des équilibrages de charge et des machines virtuelles migrés sont marquées comme étant allouées sous après la migration.
- Si votre déploiement source de vRealize Automation 7 contient une ressource non valide, par exemple s'il n'a pas de propriétés pour une ressource, la ressource n'est pas migrée. Si toutes les ressources ne sont pas valides dans le déploiement, l'intégralité du déploiement n'est pas migrée.
- Lors de la migration dans un environnement existant, les machines intégrées et migrées ne sont pas liées à des zones de cloud. Par conséquent, ces machines ne sont pas calculées dans les définitions de stockage maximales.
- Si vous migrez un déploiement avec un composant de machine unique et un composant réseau existant, vRealize Automation tente de recréer la machine existante et échoue avec l'erreur « Un sous-réseau est requis ».
- Si vous migrez un déploiement vSphere qui est lié à un modèle de cloud, puis mettez à jour le modèle de cloud après la migration, le déploiement échoue.
- Si un déploiement contient des règles DNAT, vous ne pouvez pas reconfigurer les actions du jour 2 après la migration.
- Les machines en cluster migrées ne prennent pas en charge la réduction de la charge ou la montée en charge lors de l'application de mises à jour de modèle de cloud itératives vers le déploiement parent.
- Vous pouvez uniquement migrer des déploiements en cluster à partir d'environnements sources vRealize Automation 7.6. La migration des déploiements en cluster n'est pas prise en charge pour les environnements sources vRealize Automation 7.5, 7.4 ou 7.3.
- La migration échoue si un déploiement contient 2 machines virtuelles qui sont configurées sur le même profil réseau unique, mais qui appartiennent à des réseaux différents. Avant de pouvoir migrer ce déploiement, vous devez mettre à jour les réseaux manuellement dans vCenter en modifiant l'adaptateur réseau pour qu'il soit le même pour les deux machines virtuelles. Assurez-vous que la collecte des données est terminée et que les machines virtuelles sont mises à jour avec les réseaux modifiés dans les déploiements sources.
