Migrer des hôtes avec le service Guest Introspection

Une fois que vous avez migré les passerelles de services Edge, vous pouvez migrer les hôtes NSX-V vers des nœuds de transport hôtes NSX-T.

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

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

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

Déployer un service de partenaires pour la protection de point de terminaison
Cliquez sur ce lien pour déployer un service de partenaires qui fournit uniquement une protection de point de terminaison ou des services de protection de point de terminaison et Introspection réseau aux machines virtuelles de charge de travail NSX-T.
Déployer un service de partenaires pour Introspection réseau
Cliquez sur ce lien pour déployer un service de partenaires qui fournit uniquement un service Introspection réseau aux machines virtuelles de charge de travail NSX-T.