Utilisez cette procédure si l'option « Appliqué à » est configurée dans l'une des règles DFW (cela signifie que cette option n'est pas définie sur « DFW »).

Note : Pour la migration de NSX-V vers NSX, consultez l'article de la base de connaissances https://kb.vmware.com/s/article/56991 pour plus d'informations.

Pour la migration de NSX vers NSX-V, la migration d'une machine virtuelle de charge de travail vers NSX-V peut ne pas fonctionner, car le filtre de pare-feu distribué dans NSX est toujours plus élevé que dans NSX-V. Pour résoudre ce problème, placez la machine virtuelle de charge de travail dans la liste d'exclusion de NSX avant un déplacement par vMotion.

Conditions préalables

  • Vérifiez que :
    • vSphere vMotion est activé sur l'adaptateur VMkernel de chaque hôte dans le cluster impliqué dans cette migration. Pour obtenir des instructions détaillées sur l'activation de vMotion sur l'adaptateur VMkernel, reportez-vous à la documentation du produit vSphere.
    • L'hôte de destination dans NSX dispose de ressources suffisantes pour recevoir les machines virtuelles migrées.
    • Les hôtes source et de destination sont dans un état opérationnel. Résolvez les problèmes impliquant des hôtes, y compris les états déconnectés.

Pour plus d'informations sur vMotion, consultez Migration avec vMotion dans la documentation du produit vSphere.

Procédure

  1. Exécutez un script pour spécifier un ID externe pour chaque vNIC d'une machine virtuelle et pour effectuer une migration par vMotion de la machine virtuelle vers le port logique approprié.
    Le port logique a déjà été créé par le coordinateur de migration. L'exemple de code ci-dessous (et le script dans github) détermine le paramètre external-id pour chaque vNIC afin que celle-ci se connecte au port logique qui a été créé. 
    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

  2. Appliquez les balises de sécurité et l'appartenance statique de VM aux machines virtuelles migrées.
    POST https://{nsxt-mgr-ip}/api/v1/migration/vmgroup?action=post_migrate
    Le point de terminaison de l'API vmgroup avec l'action post_migrate applique les balises de sécurité NSX-V aux machines virtuelles de charge de travail migrées sur le segment de superposition NSX.

    Pour obtenir un exemple de corps de demande de cette API, reportez-vous à la section Processus de migration « lift and shift » dans l'article de la zone technique de NSX.

  3. Finalisez l'infrastructure pour terminer la migration.
    POST https://{nsxt-mgr-ip}/api/v1/migration?action=finalize_infra
    Cette API de migration supprime toutes les configurations d'objets temporaires qui ont été créées lors de la migration, et garantit que l'infrastructure NSX est dans un état propre. Par exemple, les ensembles d'adresses IP temporaires sont supprimés des groupes.

    Cette API POST n'a pas de corps de demande.

  4. Vérifiez que tous les éléments de configuration prévus ont été migrés vers l'environnement NSX.
    Par exemple, vérifiez si les configurations suivantes sont correctement migrées :
    • Règles de pare-feu distribué définies par l'utilisateur.
    • Tous les regroupements d'objets, tels que les ensembles d'adresses IP, les groupes, les balises, etc.
    • Les membres effectifs s'affichent dans les groupes dynamiques.
    • Les balises sont appliquées aux machines virtuelles de charge de travail migrées.
  5. (Facultatif) À partir de NSX 4.1.1, lorsque la migration est terminée et avant de cliquer sur Terminer, vous pouvez cliquer sur Obtenir le rapport de migration pour voir si certains objets ont été migrés correctement. Lorsque le rapport est prêt, cliquez sur Télécharger le rapport.
    Le rapport contient les informations suivantes :
    • VM avec des balises de sécurité dans NSX-V et après avoir été migrées. Les différences seront répertoriées le cas échéant.
    • Groupes de sécurité dans NSX-V et après avoir été migrés. Les différences seront répertoriées le cas échéant.
  6. À la page Migrer les charges de travail, cliquez sur Terminer.
    Une boîte de dialogue s'affiche pour vous permettre de confirmer que vous souhaitez terminer la migration. Si vous terminez la migration, tous les détails de celle-ci s'effaceront. Vous ne pourrez plus réviser ses paramètres, Par exemple, quelles entrées ont été effectuées sur la page Résoudre la configuration.

Que faire ensuite

Après la migration réussie et minutieusement vérifiée des machines virtuelles de charge de travail et de la configuration de DFW uniquement, supprimez le pont de couche 2 pour libérer le dispositif NSX Edge que vous avez utilisé pour le pontage.