Une fois que l'infrastructure est préparée pour étendre les réseaux de couche 2, vous pouvez migrer vos hôtes NSX-V vers des nœuds de transport hôtes NSX.
Conditions préalables
- Configurez plusieurs paramètres liés à la migration de l'hôte, 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 lorsque vous utilisez un pare-feu distribué ou vSphere Distributed Switch 7.0.
- Dans l'interface utilisateur de VMware vCenter, 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 , , ou .
- Une fois que l'hôte a migré, attachez les interfaces de machine virtuelle aux segments NSX 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 , , ou .
- 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 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 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 commence.
Résultats
Après la migration d'un hôte vers NSX à 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 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.
Que faire ensuite
- 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.
Vérifiez que les machines virtuelles exécutées sur les hôtes
NSX sont connectées au segment de superposition
NSX approprié et validez la connectivité suivante :
- Connectivité entre machines virtuelles dans le réseau NSX.
- La connectivité des machines virtuelles aux machines externes en dehors du réseau NSX, à mesure que les règles DFW l'autorisent.
- À la page Migrer les hôtes, 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, tels que les données entrées à la page Résoudre la configuration, ou encore les hôtes exclus de la migration.
