Une fois que vous avez migré des machines virtuelles Edge Services Gateway vers des nœuds NSX-T Edge et vérifié que le routage et les services fonctionnent correctement, vous pouvez migrer vos hôtes NSX-V vers des nœuds de transport hôtes NSX-T.

Vous pouvez configurer plusieurs paramètres relatifs à la migration d'hôtes, y compris l'ordre de migration et l'activation des hôtes. Assurez-vous de bien comprendre les effets de ces paramètres. Pour plus d'informations, reportez-vous à la section Configuration de la migration d'hôtes NSX-V. Comprendre les paramètres de migration de l'hôte est particulièrement important si vous utilisez un pare-feu distribué ou vSphere Distributed Switch 7.0 ou une version ultérieure.

Pour plus d'informations sur les événements survenant lors de la migration d'un hôte, consultez Modifications apportées lors de la migration de l'hôte dans une migration de bout en bout.

Si les stratégies de sécurité de votre environnement NSX-V utilisent un service de partenaires pour Guest Introspection, Introspection réseau ou les deux, choisissez le mode de migration de l'hôte comme indiqué dans le tableau suivant.
Service de partenaires Mode de migration de l'hôte
Guest Introspection uniquement

Les modes Sur place et Maintenance sont pris en charge.
Introspection réseau uniquement

Le mode de maintenance est pris en charge. Cependant, le mode de maintenance automatisé est recommandé.

Le mode sur place n'est pas pris en charge.
Guest Introspection et Introspection réseau

Le mode de maintenance est pris en charge.

Le mode sur place n'est pas pris en charge.
Important : Consultez le partenaire VMware avant de migrer son service qui s'exécute sur les charges de travail NSX-V. Vérifiez auprès du partenaire si son service est pris en charge pour la migration vers NSX-T et recherchez ses entrées avant la migration. Les partenaires auront leurs propres conseils pour migrer leurs services vers NSX-T.
Attention : La migration d'hôtes doit être terminée dans la même fenêtre de maintenance que la migration Edge.

Vous devez désactiver IPFIX et redémarrer les hôtes ESXi avant de les migrer.

Si le service de partenaires de votre environnement NSX-V fournit le service Guest Introspection ou Guest Introspection et Introspection réseau, suivez la procédure décrite dans cette rubrique pour migrer cluster-par cluster. Une fois que tous les clusters d'hôtes sont migrés vers NSX-T, effectuez un déploiement de service basé sur l'hôte dans chaque cluster NSX-T.

Si le service de partenaires de votre environnement NSX-V fournit uniquement le service Introspection réseau, utilisez les approches de migration d'hôte décrites dans Migrer les hôtes avec le service d'introspection réseau.

Conditions préalables

  • Vérifiez que la migration Edge est terminée et que tous les services de routage fonctionnent correctement.
  • Dans l'interface utilisateur de vCenter Server, accédez à la page Hôtes et clusters, puis vérifiez que tous les hôtes ESXi sont dans un état opérationnel. Résolvez les problèmes impliquant des hôtes, y compris les états déconnectés. Aucun redémarrage ni aucune tâche ne doit être en attente pour entrer et sortir du mode de maintenance.

Procédure

  1. À la page Migrer les hôtes, cliquez sur Démarrer.

    Si vous avez sélectionné Sur place ou Maintenance automatique comme mode de migration pour tous les groupes d'hôtes, la migration d'hôtes commence. Notez que le coordinateur de migration ne reconfigure pas les VM hors tension en mode de maintenance Automatisé. Après la migration, vous devez configurer manuellement ces machines virtuelles avant de les mettre sous tension.

  2. Si vous avez sélectionné Maintenance manuelle comme mode de migration pour un des groupes d'hôtes, vous devez terminer l'une des tâches suivantes pour chaque machine virtuelle afin que les hôtes puissent entrer en mode de maintenance.
    Option Action
    Mettez les machines virtuelles hors tension ou interrompez-les.
    1. Faites un clic droit sur la machine virtuelle et sélectionnez Alimentation > Mise hors tension, Alimentation > Arrêter le système d'exploitation invité, ou Alimentation > Interrompre.
    2. Une fois que l'hôte a migré, attachez les interfaces de machine virtuelle aux segments NSX-T appropriés et mettez la machine virtuelle sous tension.
    Déplacez les machines virtuelles à l'aide de vMotion. Faites un clic droit sur la machine virtuelle et sélectionnez Migrer. Suivez les invites pour déplacer la machine virtuelle vers un hôte différent. Notez que le coordinateur de migration maintient la sécurité lors de la migration en connectant les VM via vMotion à des ports spécifiques protégés par des règles temporaires. Dans le cas d'une opération vMotion manuelle, les VM ne sont pas déplacées vers ces ports. Une faille de sécurité peut alors se produire. Pour utiliser vMotion manuellement, les VM doivent être migrées à l'aide de la vSphere API dans laquelle la prise en charge de la mise en réseau doit pointer vers l'ID OpaqueNetwork correspondant au segment NSX lors de l'utilisation de NVDS ou de l'ID de groupe de ports VDS lors de l'utilisation de VDS 7. Dans les deux cas, l'externalId du périphérique réseau doit être défini sur la chaîne « VM_UUID:vNIC_ID », où VM_UUID est l'UUID d'instance de la VM et vNIC_ID est l'index vNIC de la VM sur laquelle la première vNIC est 4000.
    Transférez les machines virtuelles à l'aide de la migration à froid.
    1. Faites un clic droit sur la machine virtuelle et sélectionnez Alimentation > Mise hors tension, Alimentation > Arrêter le système d'exploitation invité, ou Alimentation > Interrompre.
    2. Faites un clic droit sur la machine virtuelle et sélectionnez Migrer. Suivez les invites pour déplacer la machine virtuelle vers un hôte différent en connectant ses interfaces aux segments NSX-T appropriés.
    Voici un code Python permettant de spécifier un ID externe pour chaque vNIC dans une VM. Connectez ensuite la VM via vMotion afin que les vNIC se connectent à un segment NSX-T de l'ID « ls_id » sur les ports appropriés : 
    devices = vmObject.config.hardware.device
nic_devices = [device for device in devices if isinstance(device, vim.Vm.device.VirtualEthernetCard)]
vnic_changes = []
for device in nic_devices:
    vif_id = vmObject.config.instanceUuid + ":" + str(device.key)
    vnic_spec = self._get_nsxt_vnic_spec(device, ls_id, vif_id)
    vnic_changes.append(vnic_spec)
relocate_spec = vim.Vm.RelocateSpec()
relocate_spec.SetDeviceChange(vnic_changes)
# set other fields in the relocate_spec
vmotion_task = vmObject.Relocate(relocate_spec)
WaitForTask(vmotion_task)

def _get_nsxt_vnic_spec(self, device, ls_id, vif_id):
    nsxt_backing = vim.Vm.Device.VirtualEthernetCard.OpaqueNetworkBackingInfo()
    nsxt_backing.SetOpaqueNetworkId(ls_id)
    nsxt_backing.SetOpaqueNetworkType('nsx.LogicalSwitch')
    device.SetBacking(nsxt_backing)
    device.SetExternalId(vif_id)
    dev_spec = vim.Vm.Device.VirtualDeviceSpec()
    dev_spec.SetOperation(vim.Vm.Device.VirtualDeviceSpec.Operation.edit)
    dev_spec.SetDevice(device)
    return dev_spec

    Pour obtenir un exemple de script complet, reportez-vous à la section https://github.com/dixonly/samples/blob/main/vmotion.py

    L'hôte entre en mode de maintenance une fois que toutes les machines virtuelles sont déplacées, mises hors tension ou interrompues. Si vous voulez utiliser la migration à froid pour déplacer les machines virtuelles vers un hôte différent avant que l'hôte en cours de migration n'entre en mode de maintenance, vous devez laisser au moins une machine virtuelle en cours d'exécution pendant le déplacement des machines virtuelles. Lorsque la dernière machine virtuelle est hors tension ou interrompue, l'hôte entre en mode de maintenance et la migration de l'hôte vers NSX-T commence.

Résultats

Après la migration d'un hôte vers NSX-T à l'aide du mode de migration Sur place, vous pouvez voir une alarme critique avec le message Connectivité réseau perdue. Cette alarme se produit lorsqu'un vSphere Distributed Switch (VDS) 6.5 ou 6.7 migre vers un N-VDS, car l'hôte n'a plus de carte réseau physique connectée au VDS auquel il était précédemment connecté. Pour restaurer les hôtes migrés à l'état connecté, cliquez sur Réinitialiser sur chaque hôte et supprimez les avertissements, le cas échéant.

Si la migration d'un hôte échoue, vous pouvez déplacer son groupe d'hôtes en bas de la liste des groupes. La migration d'autres groupes d'hôtes peut continuer pendant que vous résolvez le problème de l'hôte posant problème.

Si la migration d'un hôte échoue, elle s'interrompt une fois toutes les migrations d'hôte en cours terminées. Une fois le problème avec l'hôte résolu, cliquez sur Réessayer pour retenter la migration de l'hôte échouée. Si la migration de l'hôte échoue toujours, vous pouvez configurer manuellement NSX-T sur l'hôte ou supprimer l'hôte du système. Dans ce cas, à la fin de l'étape de migration de l'hôte, le bouton Terminer ne sera pas activé en raison de l'échec de la migration de l'hôte. Vous devez appeler la REST API POST https://<nsx-mgr-IP>/api/v1/migration?action=finalize_infra (<nsx-mgr-IP> est l'adresse IP du NSX Manager sur lequel le service de migration est en cours d'exécution) à l'aide d'un client REST API (par exemple, postman ou curl) pour terminer la migration, puis effectuer les tâches de post-migration.

Pour plus d'informations sur le dépannage d'autres problèmes de migration d'hôte, consultez Dépannage des problèmes de migration.

Que faire ensuite

Si les stratégies de sécurité migrées utilisent un service de partenaires tiers, déployez une instance du service de partenaires dans NSX-T. Pour des instructions détaillées, reportez-vous aux sections :