Vous pouvez migrer votre déploiement VMware Integrated OpenStack (VIO) de NSX-V vers NSX. Pendant la migration, le plan de contrôle VIO doit être en mode lecture seule.
La connectivité du chemin de données pour les machines virtuelles n'est pas affectée pendant la migration, à l'exception de brèves interruptions lors du basculement nord-sud et de la migration de l'hôte. Cette migration doit être effectuée au cours d'une fenêtre de maintenance unique.
Présentation du processus de migration
- Installez NSX.
- Préparez NSX pour VIO. Cela nécessite la configuration de passerelles de niveau 0 ou de VRF-lite pour les réseaux externes, ainsi que la configuration de clusters Edge, de profils de serveur DHCP et de proxys de métadonnées. Pour plus d'informations, reportez-vous à la section https://docs.vmware.com/fr/VMware-Integrated-OpenStack/index.html.
- Obtenez le bundle du migrateur Neutron, qui fait partie des produits livrables VIO.
- Configurez le migrateur Neutron.
- Déployez l'espace du migrateur Neutron.
- À partir de l'interface utilisateur NSX Manager :
- Démarrez la migration du basculement Edge.
- Gérez les commentaires et terminez la migration.
- Démarrez la migration de l'hôte.
- Gérez les commentaires et terminez la migration.
- Attendez la fin de l'espace du migrateur Neutron.
- Supprimez le déploiement du migrateur Neutron.
- Supprimez l'installation de VIO dans NSX-V.
Conditions préalables
- VIO 7.2.0 ou version ultérieure
- NSX-V 6.4.11 ou version ultérieure
- vSphere 6.7 ou version ultérieure (il est recommandé de mettre à niveau les hôtes ESXi vers la version 7.0 ou version ultérieure avant la migration).
- Nombre de paires d'adresses autorisées dans Neutron (le nombre de liaisons d'adresses manuelles ne doit pas dépasser 128)
- Nombre de sous-réseaux multiples avec DHCP par commutateur logique (un seul autorisé dans NSX)
- Nombre de liaisons montantes de routeur par réseau (une seule dans NSX)
- Groupes d'hôtes : si HA pour les nœuds NSX Edge est activée et que des groupes d'hôtes sont spécifiés pour les nœuds Edge à placer. Cela générera un avertissement.
- Edge HA est ignoré dans NSX, car il ne s'applique pas. Cela générera un avertissement.
- Les réseaux de fournisseurs ou les réseaux externes basés sur un groupe de ports DVS ne sont pas pris en charge dans le plug-in NSX.
- Les réseaux VLAN à fournisseurs multiples ne sont pas pris en charge.
- Topologies d'équilibrage de charge non prises en charge par le plug-in NSX (par exemple, un équilibreur de charge avec des membres de différents sous-réseaux non reliés au même routeur Edge ou un équilibreur de charge sur un réseau non connecté à un routeur Neutron).
- Utilisation d'adresses non valides pour NSX (par exemple, qui chevauchent le réseau de transit).
- Machines virtuelles déployées sur des réseaux externes. Elles ne fonctionnent pas sur NSX.
- Accessibilité des sous-réseaux pour les membres d'équilibrage de charge. NSX nécessite que tous les sous-réseaux de l'équilibreur de charge soient attachés à la même passerelle.
Sur NSX, il ne doit pas y avoir de ressources appartenant à OpenStack (par exemple, les ressources d'un déploiement VIO précédent sur l'instance de NSX).
Reportez-vous à Migration sur place de parties spécifiques de NSX-V pour connaître les préparations nécessaires à la migration du basculement Edge et à la migration de l'hôte.
Préparation de la migration : dimensionnement du cluster NSX Edge
- Pour chaque OpenStack VIP, recherchez le sous-réseau correspondant et récupérez le routeur auquel il est lié, sauf si le sous-réseau se trouve sur un réseau externe.
- Pour chaque pool d'équilibrage de charge OpenStack, répertoriez les membres. Recherchez le sous-réseau auquel ils appartiennent et récupérez le routeur auquel le sous-réseau est lié.
Le nombre de routeurs trouvés, ainsi que la taille de l'équilibrage de charge OpenStack le plus élevé, déterminent le nombre d'emplacements de charge requis sur le cluster Edge NSX. Pour chaque équilibrage de charge, deux emplacements sont requis, pour les routeurs de service actifs et en veille. Reportez-vous à https://configmax.vmware.com pour connaître le nombre maximal d'équilibreurs de charge pouvant être exécutés sur chaque dispositif NSX Edge.
Préparation de la migration : configuration du pool d’adresses IP TEP
Lors de la migration de l'hôte, les TEP NSX-V et NSX doivent pouvoir se joindre mutuellement pour garantir la connectivité. Vous devez configurer le pool d'adresses IP TEP NSX afin qu'il puisse acheminer le trafic vers les TEP NSX-V.
Paramètres de configuration NSX-V non pris en charge dans NSX
Le tableau suivant répertorie les paramètres NSX-V non pris en charge et les motifs.
| Paramètre | Description | Motif |
|---|---|---|
| cluster_moid | Répertorie les ID des clusters utilisés par Openstack. | Non applicable dans NSX. |
| datacenter_moid |
Identifie le centre de données pour le déploiement des dispositifs Edge NSX-V. | Non applicable dans NSX. |
| deployment_container_id |
Identifie le conteneur de déploiement pour les dispositifs Edge NSX-V. | Non applicable dans NSX. |
| resource_pool_id |
Identifie le pool de ressources pour les dispositifs Edge NSX-V. | Non applicable dans NSX. |
| datastore_id |
Identifie la banque de données pour les dispositifs Edge NSX-V. | Non applicable dans NSX. |
| ha_datastore_id |
Banque de données supplémentaire si Edge HA est activé. | Non applicable dans NSX. |
| ha_placement_random |
Divisez les dispositifs Edge actifs entre la banque de données principale et la banque de données secondaire. | Non applicable dans NSX. |
| edge_host_groups |
Assurez-vous que les dispositifs Edge actifs/de sauvegarde sont placés dans les groupes d'hôtes répertoriés. | Non applicable dans NSX. |
| external_network |
ID de DVPG à utiliser pour la liaison montante réseau physique. | Non applicable dans NSX. |
| task_status_check_interval |
Intervalle de vérification de l'achèvement des tâches. | Non applicable dans NSX. |
| vdn_scope_id |
ID de l'objet de portée réseau pour les câbles virtuels VXLAN. | Les étendues VDN sont remplacées par les zones de transport de superposition NSX. |
| dvs_id |
ID du DVS connecté au cluster de gestion et Edge. Également utilisé par défaut pour les réseaux VLAN. | DVS est remplacé par la zone de transport VLAN dans NSX. |
| maximum_tunnels_per_vnic |
Nombre maximal de sous-interfaces prises en charge par une VNIC sur un dispositif Edge. | Non applicable dans NSX. |
| backup_edge_pool |
Définit la taille du pool Edge NSX-V à utiliser par le déploiement Openstack. | Non applicable dans NSX. |
| mgm_net_moid |
ID du groupe de ports pour le réseau de gestion du proxy de métadonnées. | Non applicable dans NSX. |
| mgt_net_proxy_ips |
Liste d'adresses IP de réseau de gestion séparées par des virgules. | Non applicable dans NSX. |
| mgt_net_proxy_netmask |
Masque de réseau du réseau de gestion pour le proxy de métadonnées. | Non applicable dans NSX. |
| mgt_net_default_gateway |
Passerelle par défaut du réseau de gestion pour le proxy de métadonnées. | Non applicable dans NSX. |
| nova_metadata_ips |
Adresses IP utilisées par le service de métadonnées Nova. | Fourni dans la configuration du proxy de métadonnées NSX. |
| nova_metadat_port |
Port utilisé par le service de métadonnées Nova. | Fourni dans la configuration du proxy de métadonnées NSX. |
| spoofguard_enabled |
Par défaut, Spoofguard est activé dans NSX-V, mais si vous le désactivez dans NSX-V, il sera activé dans NSX après la migration. | Activé par défaut dans NSX (ne peut pas être désactivé globalement). |
| use_exclude_list |
Utilisez le composant de liste NSX-V lorsque la sécurité de port est désactivée et que Spoofguard est activé. | Activé par défaut dans NSX (ne peut pas être désactivé globalement). |
| tenant_router_types |
Liste ordonnée des types de routeurs à allouer en tant que routeurs locataires. | Non applicable dans NSX. |
| edge_appliance_user |
Nom d'utilisateur à configurer pour la connexion au dispositif Edge. | Non applicable dans NSX. |
| metadata_initializer |
Initialiser l'infrastructure d'accès aux métadonnées | Non applicable dans NSX. |
| shared_router_appliance_size |
Taille du dispositif Edge à utiliser pour créer un dispositif Edge de routeur partagé. | Non applicable dans NSX. |
| use_dvs_features |
Autoriser la configuration directe de la sauvegarde DVS prenant en charge NSX-V. | Non applicable dans NSX. |
| service_insertion_profile_id |
ID de profil des règles de pare-feu de redirection qui seront utilisées pour l'insertion de services. | La fonctionnalité n'existe pas dans l'intégration NSX. |
| service_insertion_redirect_all |
Crée une règle de pare-feu pour rediriger tout le trafic vers un pare-feu tiers. | La fonctionnalité n'existe pas dans l'intégration NSX. |
| use_nsx_policies |
Utiliser des stratégies NSX pour l'implémentation de groupes de sécurité Neutron. | La fonctionnalité n'existe pas dans l'intégration NSX. |
| default_policy_id |
Si use_nsx_policies est True, cette stratégie sera utilisée comme stratégie par défaut pour les nouveaux locataires |
La fonctionnalité n'existe pas dans l'intégration NSX. |
| bind_floatingip_to_all_interfaces |
Lier les adresses IP flottantes aux interfaces de liaison descendante lorsqu'elles sont définies sur True. |
Dans NSX, NAT pour l'adresse IP flottante est toujours traitée également pour le trafic horizontal. |
| vdr_transit_network |
Plage réseau pour la connectivité TLR/PLR du routeur distribué. | Dans NSX, la plage de connectivité DR/SR ne peut pas être configurée à partir d'OpenStack. |
| exclusive_dhcp_edge |
Disposer d'un dispositif Edge DHCP exclusif par réseau | Ne s'applique pas à NSX, car DHCP est implémenté sur le cluster Edge. |
| bgp_neighbour_hold_down_timer |
Intervalle de retenue du voisin BGP. | La fonctionnalité n'existe pas dans l'intégration NSX. L'appairage BGP est configuré sur la configuration du routage de passerelle de niveau 0 NSX. |
| bgp_neighbour_keep_alive_timer |
Intervalle de durée de survie du voisin. | La fonctionnalité n'existe pas dans l'intégration NSX. L'appairage BGP est configuré sur la configuration du routage de passerelle de niveau 0 NSX. |
| share_edges_between_tenants |
Utilisez le même dispositif DHCP ou le même dispositif Edge de routeur pour plusieurs locataires. | Non applicable dans NSX. |
| use_routers_as_lbaas_platform |
Utilisez le routeur exclusif du sous-réseau comme plate-forme pour LBaaS. | Non applicable dans NSX, où les services d'équilibrage de charge sont toujours attachés à des serveurs utilisés pour le transfert. |
| nsx_sg_name_format |
Format du nom NSX d'un groupe de sécurité OpenStack. | La dénomination des ressources du serveur principal est implicite dans NSX. |
| loadbalancer_pool_transparency |
Créez des pools LBaaS en mode Transparent. | Le mode Transparent n'est pas pris en charge dans NSX. |
| default_edge_size |
Définit la taille Edge par défaut pour le routeur, DHCP et les dispositifs Edge d'équilibrage de charge. | Non applicable dans NSX. |
Configuration du migrateur 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"
}
Les paramètres de configuration sont les suivants :
| Paramètre | Valeur par défaut | Description |
|---|---|---|
| post_migration_cleanup | Vrai | Une fois la migration terminée, supprimez les entités NSX supplémentaires créées par le processus de migration qui ne sont pas utilisées par VIO ou dupliquées par d'autres ressources VIO. |
| restauration | Vrai | Restauration automatique en cas d'échec (si possible). |
| nsxv_token_lifetime | 1440 | Durée en minutes du jeton pour l'accès NSX-V. Le jeton est fourni à NSX. La durée doit être choisie en fonction de la taille du déploiement et de la durée attendue pour terminer la migration. Le jeton ne doit pas expirer avant la fin de la migration. |
| compute_clusters | Liste des clusters de calcul vSphere qui seront migrés. Cela ne doit inclure que les clusters sur lesquels des instances de VM VIO sont déployées. Les clusters Edge et les clusters de gestion VIO ne doivent pas être inclus. | |
| nsx_manager_ips | Adresse IP ou nom de domaine complet de NSX Manager. Si un cluster de gestionnaires est utilisé, ce paramètre peut spécifier une adresse IP virtuelle ou la liste des instances de NSX Manager. Dans ce dernier cas, l'équilibrage de charge côté client est utilisé lors de l'accès à NSX Manager. | |
| nsx_manager_user | admin | Utilisateur pour l'accès NSX Manager. L'authentification avec identités de principal n'est pas prise en charge par VIO. |
| nsx_manager_password | Mot de passe pour l’accès NSX Manager. | |
| metadata_proxy | Identifiant du proxy de métadonnées pour la zone de disponibilité VIO par défaut. L'identifiant est le dernier segment du chemin de stratégie de la ressource. | |
| dhcp_profile | Identifiant du profil DHCP pour la zone de disponibilité VIO par défaut. | |
| default_tier0_router | Identifiant de la passerelle de niveau 0 pour la zone de disponibilité VIO par défaut. Cela est utilisé pour le trafic nord-sud par les routeurs Neutron dont la passerelle est le réseau externe par défaut. | |
| default_overlay_tz | Zone de transport NSX à utiliser pour le déploiement de VIO. | |
| default_vlan_tz | Zone de transport VLAN NSX pour la zone de disponibilité par défaut. | |
| transit_network | 100.64.0.0/16 | CIDR pour le réseau de transit NSX. Modifiez uniquement s'il a été modifié de la valeur par défaut NSX. |
| external_networks_map | Liste vide | |
| availability_zones | Liste vide |
Déploiement du migrateur Neutron
./build_yaml.sh -t 7.1.1.1899999
| -k | Facultatif. N'incluez pas le certificat vCenter Server dans le déploiement. Spécifiez cette option uniquement lorsque VIO utilise une connexion vCenter non sécurisée. |
| -t <full VIO version> | Requis. La version de VIO doit inclure le numéro de build et la balise de correspondance pour les images VIO existantes. |
Le script build_yaml.sh crée <YAML-FILE-NAME> qui contient toutes les informations de déploiement du plan de contrôle du migrateur Neutron.
Démarrage de la migration
kubectl apply -f <YAML-FILE-NAME>
Cela créera le déploiement du migrateur Neutron dans l'espace de noms Openstack. Ce déploiement dispose d'un seul réplica. L'espace de migration est automatiquement démarré lors de la création de l'espace du déploiement.
Démarrage de l'espace de migration
- Relecture d’API
- Démarrage de la migration depuis NSX Manager
- Reconfiguration de VIO
L'espace de migration se terminera si le fichier de configuration est introuvable ou si certains paramètres requis n'ont pas été spécifiés.
L'espace de migration se termine également avec une erreur si l'état actuel de la migration est incohérent, par exemple, si la relecture d'API n'est pas terminée, mais qu'une migration est déjà en cours.
Lorsque la tâche de migration est démarrée, les fichiers de configuration des plug-ins Neutron NSX sont montés dans l'espace. Toute modification apportée à la configuration Neutron une fois la migration démarrée ne sera pas traitée par la tâche de migration. Vous ne devez pas apporter de modifications à la configuration Neutron lorsque l’opération de migration est en cours d’exécution. Si vous devez apporter des modifications, le travail de migration doit être redémarré.
Relecture d’API
Dans cet état, le processus de migration créera toutes les configurations nécessaires sur NSX et remplira la base de données VIO Neutron à utiliser avec NSX.
À la fin de ce processus, toutes les entités de mise en réseau logique requises par VIO seront configurées dans NSX, même si les charges de travail sont toujours en cours d'exécution sur NSX-V.
- Vérifications préalables à la validation. Il s'agit des vérifications répertoriées dans la section Conditions préalables ci-dessus.
- Vérification de la version NSX. La version de NSX doit être 3.2 ou une version ultérieure.
- Assurez-vous que le gestionnaire de calcul est configuré. La migration nécessite que l'instance de vCenter de VIO soit enregistrée en tant que gestionnaire de calcul dans NSX. Cette vérification vérifie que cette opération a été effectuée.
- Aucune ressource Neutron ne doit être configurée sur NSX. Si l'option de restauration est définie sur True, le processus de migration nettoie toute ressource Neutron (probablement périmée) trouvée sur NSX.
Une fois les vérifications terminées, le processus de migration initialise la base de données Neutron NSX et prépare sa structure. Ensuite, un serveur Neutron temporaire est démarré dans l’espace du migrateur. Ce serveur Neutron temporaire a été configuré pour s'exécuter avec NSX. Une fois le serveur Neutron temporaire actif, le processus de migration collecte des informations sur les mappages VNI réseau et les mappages de port/VIF.
- Routeurs (vers les passerelles de niveau 1)
- Réseaux (vers segments)
- Sous-réseaux (vers la configuration DHCP des sous-réseaux de segments et des segments)
- Port (vers les ports de segment et les liaisons statiques DHCP)
- Groupes de sécurité (pour les stratégies de sécurité, les règles, les groupes et les services)
- Adresses IP flottantes (vers règles NAT)
- Stratégies et règles QoS
- Groupes, stratégies et règles FWaaS
- Équilibreurs de charge, écouteurs, pools, membres et moniteurs de santé Octavia
Une fois la relecture de l'API terminée, l'espace du serveur Neutron temporaire est arrêté.
Surveillez les journaux de l'espace du migrateur à l'aide de la commande tail. Lorsque les journaux indiquent que l'espace du migrateur attend le démarrage du processus de migration NSX, effectuez la tâche suivante (basculement Edge).
Basculement 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}'
- Arrêter les interfaces du dispositif Edge NSX-V.
- Activer ARP sur la liaison descendante de niveau 1 NSX pour garantir une transition transparente du trafic est-ouest et nord-sud pendant la migration.
- Connectez-vous à vCenter pour récupérer un jeton d'authentification NSX-V.
- Préparez un fichier de mappage pour les routeurs distribués (DLR NSX-V).
- Configurez la migration Edge sur NSX et attendez qu'elle soit terminée.
Pendant le basculement nord-sud, les machines virtuelles peuvent perdre brièvement la connectivité, car la connectivité passe de passerelles ESG NSX-V ou de DLR aux passerelles de niveau 1 NSX. Une fois le basculement nord-sud terminé, les dispositifs NSX-V et de métadonnées sont mis hors tension. L'étape suivante consiste à migrer l'hôte.
IMPORTANT : avant de démarrer le basculement nord-sud, après une restauration, assurez-vous que le fichier de mappage Edge est présent. Le fichier est automatiquement supprimé après une restauration. Le travail du migrateur le restaure dans les 10 secondes qui suivent l'exécution de la restauration. Cela ne s'applique pas s'il n'existe aucun routeur distribué dans l'environnement VIO NSX-V.
Remarque : le jeton d'accès NSX-V est renouvelé à chaque exécution de l'espace. La durée doit être suffisamment longue pour s'assurer que la migration est terminée dans le cycle de vie de l'espace du migrateur. Si l'espace du migrateur est redémarré pour une raison quelconque, un nouveau jeton sera extrait.
Migration d'hôte
Suivez la procédure dans Migration de la configuration du pare-feu distribué, des hôtes et des charges de travail.
- Mettre hors tension tous les dispositifs Edge NSX-V.
- Configurer la migration de l'hôte sur NSX.
- Attendre la fin de la migration de l'hôte.
La mise hors tension des dispositifs Edge est nécessaire pour garantir la réussite de la migration de l'hôte. Ne mettez pas sous tension les dispositifs Edge NSX-V lors de la migration de l'hôte.
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}'
Nettoyage après la migration
La tâche de migration reconfigure la CR Neutron pour utiliser NSX, mais ne supprime pas les paramètres de configuration NSX-V afin que vous puissiez les afficher à des fins de référence. Ces paramètres sont inoffensifs. Une fois la migration terminée, vous pouvez les supprimer à l'aide de la commande viocli update neutron.
Journalisation
Le processus du migrateur Neutron produit une journalisation détaillée pour chaque phase du processus. Les journaux écrits sur le stdout de l'espace sont au niveau INFO. Les journaux de niveau débogage se trouvent à /var/log/migration/vio-v2t.log sur le nœud du contrôleur VIO sur lequel l'espace du migrateur est en cours d'exécution.
osctl get pods neutron-migrator -o wide
Vous pouvez ensuite utiliser la commande viossh pour ouvrir un shell sur le nœud de contrôleur.
Le répertoire /var/log/migration contient également le journal temporaire du serveur Neutron.
Restauration
La restauration peut se produire à diverses étapes pendant la migration.
Si une panne se produit lors de l'étape de relecture d'API, une restauration explicite n'est pas nécessaire. L'utilitaire du migrateur Neutron VIO supprimera automatiquement les ressources qui ont été créées, puis retentera la migration.
Si vous choisissez d'interroger la migration en détruisant l'espace du migrateur Neutron, le plan de contrôle VIO sera toujours fonctionnel dans NSX-V. Il peut y avoir des ressources NSX créées par la relecture d'API. Ces ressources seront supprimées.
Notez que NSX n'autorise pas la restauration de la migration de l'hôte. Une fois que les hôtes ont été migrés vers NSX, il ne sera pas possible de les replacer dans NSX-V.
Si une panne se produit lors de la migration de l'hôte, vous pouvez consulter les journaux et résoudre le problème.
Si un hôte ne parvient pas systématiquement à migrer vers NSX, vous pouvez le supprimer du cluster vSphere et réessayer la migration. Les machines virtuelles en cours d'exécution sur l'hôte affecté seront migrées vers d'autres hôtes du cluster. Après la migration, installez NSX sur l'hôte et ajoutez-le au cluster vSphere d'origine.
Codes d'erreur
| Code | Description |
|---|---|
| 0001, 0002, 0003, 0004 | État ou configuration du système incorrect. Il existe des problèmes majeurs avec la migration, tels que :
|
| 0101 | Impossible de créer des fichiers de configuration pour le serveur Neutron temporaire, qui doit être actif pour la relecture d'API. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. Cette erreur peut généralement être résolue en corrigeant la cause principale des modifications apportées au fichier de configuration. |
| 1001 | Le coordinateur de migration NSX n'est pas en cours d'exécution. Pour corriger cette erreur, démarrez le service de coordinateur de migration sur le premier nœud spécifié dans migrator.conf.json. Si vous utilisez l'adresse IP virtuelle HA, assurez-vous que l'instance du gestionnaire actif est celle sur laquelle le coordinateur de migration est en cours d'exécution. Pour la migration, il est recommandé d'utiliser un gestionnaire NSX spécifique ou d'utiliser l'équilibrage de charge côté client. Les noms de domaine complets de NSX Manager peuvent être modifiés une fois la migration terminée. |
| 1002 | Version non valide de NSX. NSX 3.2.0 ou version ultérieure est requis. |
| 1003 | Impossible de récupérer la version de NSX. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. |
| 1004 | Échec de la validation du gestionnaire de calcul. Il doit y avoir au moins un gestionnaire de calcul défini dans NSX. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. |
| 1005 | Vous devez exécuter le nettoyage sur NSX. La configuration NSX dispose déjà de ressources créées par VIO. Assurez-vous que rollback est défini sur True dans migrator.conf.json. |
| 1006 | Impossible de démarrer la migration NSX. Cela est probablement dû à une tentative de migration précédente. Restaurez toute migration en cours et réessayez. |
| 1007 | Impossible de préparer NSX pour le basculement nord-sud. Une erreur s'est produite lors de la configuration du basculement nord-sud sur NSX. Il peut s'agir d'une erreur lors de la génération du fichier « mappages Edge » ou d'une erreur lors de la préparation du plan de migration. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. |
| 1008 | L'espace du migrateur ne parvient pas à arrêter les interfaces sur les dispositifs Edge NSX. Il s'agit d'une étape requise pour le basculement nord-sud. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. Pour résoudre ce problème, définissez edge_migration_interfaces_down sur False dans migrator.conf.json et assurez-vous manuellement que les interfaces Edge sont inactives ou déconnectées avant de démarrer le basculement nord-sud. |
| 1009 | Impossible de migrer des routeurs sans liaisons descendantes. Il existe un routeur Neutron sans liaisons descendantes. Elles ne peuvent pas être migrées. Si l'opérateur pense que cette erreur est renvoyée par erreur, elle peut être ignorée en définissant advanced_router_validation sur False dans migrator.conf.json. |
| 1100 | Mode non valide dans le plan de migration. Le coordinateur de migration NSX est déjà configuré avec un autre plan. Cela est probablement dû à une tentative de migration précédente. Restaurez toute migration en cours et réessayez. |
| 1101 | Migration de NSX non reconnue dans la configuration. Assurez-vous que edge_migration et/ou host_migration sont définis sur True dans migration.conf.json. |
| 1105 | Impossible de corriger les routeurs sans passerelle. Le processus visant à garantir que les routeurs Neutron sans passerelle peuvent être migrés facilement vers NSX a échoué. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. En définissant advanced_router_validation sur False, ce processus sera ignoré. Il incombe toutefois à l'opérateur de s'assurer que chaque passerelle de niveau 1 est connectée à un routeur de niveau 0 avant de démarrer le basculement nord-sud sur NSX. |
| 1106 | Impossible de restaurer des routeurs sans passerelle. Le processus de restauration des routeurs Neutron sans passerelle après le basculement nord-sud a échoué. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. En définissant advanced_router_validation sur False, ce processus sera ignoré. Il revient toutefois à l'opérateur de s'assurer que les passerelles de niveau 1 sont déconnectées du niveau 0 pour les routeurs Neutron sans passerelles. |
| 1110 | Impossible de démarrer la migration du basculement nord-sud vers NSX. Une erreur s'est produite lors de l'application du plan de migration. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. |
| 1114 | VM manquante pour les dispositifs Edge. Certains dispositifs Edge n'ont pas de dispositif de machine virtuelle associé. Supprimez le routeur Neutron correspondant afin que le dispositif Edge soit supprimé. |
| 1115 | Impossible de mettre hors tension les machines virtuelles Edge NSX-V avant de démarrer la migration de l'hôte. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. Vous pouvez envisager de mettre hors tension les machines virtuelles manuellement. Cela est nécessaire pour éviter les problèmes lors de la phase d'exécution de la migration de l'hôte. Vous devez au moins mettre hors tension les dispositifs Edge DHCP et de proxy de métadonnées. |
| 1120 | Impossible de démarrer la migration de l'hôte. Une erreur s'est produite lors de l'application du plan de migration. Recherchez les détails des erreurs dans les journaux d'espace de travail du migrateur ou /var/log/migration/vio-v2t.log. |
| 1130, 1131 | Impossible de terminer la migration. Erreur lors de la définition de la migration comme terminée. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. |
| 1132 | Délai d'expiration pendant la migration. Le délai d'expiration du basculement nord-sud est de 12 heures. Le délai d'expiration de la migration de l'hôte est de 48 heures. Si l'espace de travail du migrateur est laissé en attente du démarrage d'une migration, celui-ci finit par expirer. L'utilisateur doit simplement le redémarrer. |
| 2001 | Impossible de récupérer la CR Neutron à partir du plan de contrôle VIO. Il peut s'agir d'un problème d'autorisation ou d'un problème lors de l'accès au plan de contrôle Kubernetes de VIO. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. |
| 2002 | Impossible d'analyser la CR Neutron. Assurez-vous qu'il existe un attribut 'manifests' dans la section 'spec'. |
| 2003 | Contenu non valide dans la CR Neutron. Assurez-vous que le plug-in NSX-V est activé et que tous les autres plug-ins, y compris le plug-in NSX Policy, sont désactivés. |
| 2004 | Impossible de mettre à jour la CR Neutron. Une erreur s'est produite lors de la mise à jour de la CR Neutron. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. Il peut s'agir d'une erreur lors de la mise à jour de la CR Neutron, de la création de l'instance VIOSecret pour le mot de passe NSX ou de la création de ressources pour NSX Manager. Vérifiez que ces ressources n'ont pas été laissées périmées après une tentative infructueuse précédente. |
| 2011 | Un échec s'est produit lors de la création d'une base de données pour NSX avec la stratégie. Il s'agit probablement d'une erreur SQL. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. |
| 2012 | Un échec s'est produit lors du changement de nom de la base de données « neutron_policy » en « neutron ». Il s'agit probablement d'une erreur SQL. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. |
| 2111 | Le serveur Neutron temporaire utilisé pour la relecture d'API n'a pas pu être démarré. Il s'agit probablement d'une erreur dans la configuration du serveur Neutron temporaire. Recherchez les erreurs dans /var/log/neutron-server-tmp.log. |
| 2112 | Échec de la relecture d’API. Cela indique une erreur lors de la création de ressources dans NSX. Recherchez les erreurs dans les journaux d'espace de travail du migrateur ou dans /var/log/migration/vio-v2t.log. Les journaux indiquent quelle ressource n'a pas pu être créée. Vérifiez ensuite /var/log/neutron-server-tmp.log pour obtenir les détails de l'échec. Raisons d'échec courantes :
|
