Vous pouvez migrer votre déploiement VMware Integrated OpenStack (VIO) de NSX-V vers NSX-T. 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

  1. Installez NSX-T.
  2. Préparez NSX-T 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.
  3. Obtenez le bundle du migrateur Neutron, qui fait partie des produits livrables VIO.
  4. Configurez le migrateur Neutron.
  5. Déployez l'espace du migrateur Neutron.
  6. À 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.
  7. Attendez la fin de l'espace du migrateur Neutron.
  8. Supprimez le déploiement du migrateur Neutron.
  9. 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).
L'espace du migrateur Neutron exécutera les contrôles de validation suivants. Les vérifications générant un avertissement peuvent être contournées via la configuration du migrateur Neutron.
  • 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-T)
  • Nombre de liaisons montantes de routeur par réseau (une seule dans NSX-T)
  • 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-T, 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-T.
  • 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-T (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-T (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-T.
  • Accessibilité des sous-réseaux pour les membres d'équilibrage de charge. NSX-T nécessite que tous les sous-réseaux de l'équilibreur de charge soient attachés à la même passerelle.

Sur NSX-T, 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-T).

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

Le cluster Edge NSX-T doit disposer de suffisamment d'emplacements pour les équilibreurs de charge OpenStack (LB). Pour déterminer la liste des passerelles de niveau 1 qui hébergeront un service d'équilibrage de charge, procédez comme suit :
  • 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-T. 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-T 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-T doivent pouvoir se joindre mutuellement pour garantir la connectivité. Vous devez configurer le pool d'adresses IP TEP NSX-T afin qu'il puisse acheminer le trafic vers les TEP NSX-V.

Paramètres de configuration NSX-V non pris en charge dans NSX-T

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

datacenter_moid

Identifie le centre de données pour le déploiement des dispositifs Edge NSX-V. Non applicable dans NSX-T.

deployment_container_id

Identifie le conteneur de déploiement pour les dispositifs Edge NSX-V. Non applicable dans NSX-T.

resource_pool_id

Identifie le pool de ressources pour les dispositifs Edge NSX-V. Non applicable dans NSX-T.

datastore_id

Identifie la banque de données pour les dispositifs Edge NSX-V. Non applicable dans NSX-T.

ha_datastore_id

Banque de données supplémentaire si Edge HA est activé. Non applicable dans NSX-T.

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

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

external_network

ID de DVPG à utiliser pour la liaison montante réseau physique. Non applicable dans NSX-T.

task_status_check_interval

Intervalle de vérification de l'achèvement des tâches. Non applicable dans NSX-T.

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

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

maximum_tunnels_per_vnic

Nombre maximal de sous-interfaces prises en charge par une VNIC sur un dispositif Edge. Non applicable dans NSX-T.

backup_edge_pool

Définit la taille du pool Edge NSX-V à utiliser par le déploiement Openstack. Non applicable dans NSX-T.

mgm_net_moid

ID du groupe de ports pour le réseau de gestion du proxy de métadonnées. Non applicable dans NSX-T.

mgt_net_proxy_ips

Liste d'adresses IP de réseau de gestion séparées par des virgules. Non applicable dans NSX-T.

mgt_net_proxy_netmask

Masque de réseau du réseau de gestion pour le proxy de métadonnées. Non applicable dans NSX-T.

mgt_net_default_gateway

Passerelle par défaut du réseau de gestion pour le proxy de métadonnées. Non applicable dans NSX-T.

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

nova_metadat_port

Port utilisé par le service de métadonnées Nova. Fourni dans la configuration du proxy de métadonnées NSX-T.

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-T après la migration. Activé par défaut dans NSX-T (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-T (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-T.

edge_appliance_user

Nom d'utilisateur à configurer pour la connexion au dispositif Edge. Non applicable dans NSX-T.

metadata_initializer

Initialiser l'infrastructure d'accès aux métadonnées Non applicable dans NSX-T.

shared_router_appliance_size

Taille du dispositif Edge à utiliser pour créer un dispositif Edge de routeur partagé. Non applicable dans NSX-T.

use_dvs_features

Autoriser la configuration directe de la sauvegarde DVS prenant en charge NSX-V. Non applicable dans NSX-T.

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

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

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

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

bind_floatingip_to_all_interfaces

Lier les adresses IP flottantes aux interfaces de liaison descendante lorsqu'elles sont définies sur True. Dans NSX-T, 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-T, 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-T, 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-T. 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-T. 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-T.

use_routers_as_lbaas_platform

Utilisez le routeur exclusif du sous-réseau comme plate-forme pour LBaaS. Non applicable dans NSX-T, 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-T.

loadbalancer_pool_transparency

Créez des pools LBaaS en mode Transparent. Le mode Transparent n'est pas pris en charge dans NSX-T.

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

Configuration du migrateur Neutron

Avant de lancer le migrateur Neutron, créez un fichier JSON appelé migrator.conf.json pour spécifier l'environnement NSX-T et les hôtes à migrer. Ce fichier sera monté dans l'espace du migrateur et validé par le processus de migration. Voici un exemple de fichier migrator.conf.json :
{
 "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-T 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-T. 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-T 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-T à utiliser pour le déploiement de VIO.
default_vlan_tz Zone de transport VLAN NSX-T pour la zone de disponibilité par défaut.
transit_network 100.64.0.0/16 CIDR pour le réseau de transit NSX-T. Modifiez uniquement s'il a été modifié de la valeur par défaut NSX-T.
external_networks_map Liste vide
availability_zones Liste vide

Déploiement du migrateur Neutron

Dans le bundle du migrateur se trouve un script appelé script build_yaml.sh. Lorsque la configuration de migration est prête, exécutez le script pour créer la spécification de déploiement et la déployer sur le plan de contrôle VIO. Par exemple :
./build_yaml.sh -t 7.1.1.1899999
Le script accepte les paramètres suivants :
-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

Pour démarrer la migration, exécutez la commande suivante :
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

Lors du démarrage, l'espace de migration lit le fichier de configuration et l'état actuel de la migration. En fonction de ces informations, il décide de l'étape suivante de la migration, qui peut être l'une des suivantes :
  • 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-T et remplira la base de données VIO Neutron à utiliser avec NSX-T.

À la fin de ce processus, toutes les entités de mise en réseau logique requises par VIO seront configurées dans NSX-T, même si les charges de travail sont toujours en cours d'exécution sur NSX-V.

Avant d'implémenter la configuration VIO sur NSX-T, les vérifications suivantes sont effectuées :
  • 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-T. La version de NSX-T 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-T. Cette vérification vérifie que cette opération a été effectuée.
  • Aucune ressource Neutron ne doit être configurée sur NSX-T. 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-T.

Une fois les vérifications terminées, le processus de migration initialise la base de données Neutron NSX-T 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-T. 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.

Le processus de migration de l'API est alors démarré et migre les ressources suivantes :
  • 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-T, effectuez la tâche suivante (basculement Edge).

Basculement Edge

Effectuez l'appel d'API suivant pour obtenir l'ID du nœud Edge :
curl -v -s -X GET -k -u admin:<password> https://<nsx-mgr-ip>/api/v1/transport-nodes/ -H content-type:application/json
Effectuez l'appel d'API suivant pour modifier le paramètre v2t-migration-config sur tous les nœuds Edge :
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}'
Suivez la procédure dans Migration du trafic nord-sud vers les dispositifs NSX-T Edge à l'aide du basculement Edge. Après cette migration, le trafic nord-sud est géré par NSX-T. Le processus de migration :
  • Arrêter les interfaces du dispositif Edge NSX-V.
  • Activer ARP sur la liaison descendante de niveau 1 NSX-T 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-T 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-T. 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.

L'utilitaire de migration VIO effectuera les actions suivantes :
  • Mettre hors tension tous les dispositifs Edge NSX-V.
  • Configurer la migration de l'hôte sur NSX-T.
  • 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.

Une fois la migration de l'hôte terminée, effectuez l'appel d'API suivant pour réinitialiser le paramètre v2t-migration-config pour les nœuds Edge. Ce paramètre a été défini au début de l'étape de basculement Edge.
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-T, 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.

Vous pouvez savoir sur quel nœud l'espace du migrateur Neutron est exécuté à l'aide de la commande suivante :
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-T créées par la relecture d'API. Ces ressources seront supprimées.

Notez que NSX-T n'autorise pas la restauration de la migration de l'hôte. Une fois que les hôtes ont été migrés vers NSX-T, 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-T, 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-T 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 :
  • La migration de l'API est déjà terminée, mais la relecture d'API n'a pas été effectuée.
  • VIO s'exécute déjà avec NSX-T, mais la relecture ou la migration de l'API n'est pas effectuée.
  • Hôtes sur NSX-T, VIO s'exécutant avec NSX-T, mais la relecture d'API n'est pas effectuée.
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-T Manager peuvent être modifiés une fois la migration terminée.
1002 Version non valide de NSX-T. NSX 3.2.0 ou version ultérieure est requis.
1003 Impossible de récupérer la version de NSX-T. 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-T. 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-T. La configuration NSX-T 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-T. 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-T 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-T. 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-T 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-T 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-T 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-T.
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-T. 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-T 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-T 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-T 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-T. 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 :
  • Zones de transport incorrectes dans la configuration temporaire du serveur Neutron
  • Réseaux non-Openstack utilisant le même VLAN que certains réseaux Openstack
  • Cluster Edge à court d'emplacements pour les équilibreurs de charge