Objectif
Créer un réseau VMkernel dédié à vMotion sur les hôtes ESXi, en isolant ce trafic sur un VLAN fiable, en vérifiant la cohérence MTU et la redondance des uplinks, puis en testant une migration à chaud avant généralisation.
Prérequis
- vCenter et hôtes ESXi opérationnels et compatibles entre eux.
- VLAN vMotion et plan IP dédiés avec une adresse statique par hôte.
- Port-group standard ou distribué prévu pour vMotion.
- Trunks physiques configurés sur tous les hôtes concernés.
- Capacité réseau adaptée et, idéalement, au moins un uplink de secours.
Procédure pas à pas
Inventorier les VMkernel et uplinks existants
Avant création, relevez les VMkernel de management, stockage et vMotion déjà configurés. Identifiez les uplinks physiques, les vSwitch ou dvSwitch et les VLAN. Vérifiez qu’aucune adresse du nouveau réseau n’est déjà utilisée. Cette cartographie évite de placer vMotion sur le mauvais vSwitch ou de créer une route VMkernel ambiguë.
esxcli network ip interface listesxcli network nic list- Le design actuel et les uplinks disponibles sont connus.
Préparer le VLAN sur l’infrastructure physique
Ajoutez le VLAN vMotion aux trunks qui relient les hôtes. Évitez de le transporter sur des ports qui n’en ont pas besoin. Si une paire de switches est utilisée, vérifiez que le VLAN et les LAG/teaming sont cohérents des deux côtés. Pour une migration inter-rack ou inter-site, confirmez la latence et le routage supportés par votre design.
- Le VLAN vMotion est disponible de bout en bout entre les hôtes.
Créer ou choisir le port-group vMotion
Sur chaque hôte ou sur le distributed switch
- Le port-group vMotion existe avec le bon VLAN et les bons uplinks.
Créer l’adaptateur VMkernel
Ajoutez un VMkernel sur le port-group puis activez le service vMotion. Attribuez une adresse statique du réseau dédié. Répétez l’opération sur tous les hôtes qui doivent migrer entre eux. La configuration vMotion doit être activée uniquement sur les VMkernel prévus, afin d’éviter que le trafic emprunte un autre réseau par défaut.
- Chaque hôte possède un VMkernel vMotion avec une IP unique et le service vMotion activé.
Valider le MTU de bout en bout
Si le réseau utilise MTU 1500, vérifiez simplement l’absence de configuration jumbo partielle. Si vous choisissez 9000, contrôlez la même valeur sur VMkernel, switch virtuel et réseau physique. Utilisez vmkping avec l’interface source vMotion et la taille de paquet adaptée pour détecter une fragmentation ou un équipement intermédiaire mal configuré.
vmkping -I <VMK-Vmotion> <IP-VMOTION-PAIR>vmkping -I <VMK-Vmotion> -d -s 8972 <IP-VMOTION-PAIR>- Le vmkping réussit entre chaque paire d’hôtes avec la MTU attendue.
Note : Le test jumbo n’est pertinent que si le réseau est réellement configuré en MTU 9000 de bout en bout.
Vérifier la redondance des uplinks
Contrôlez les NIC actives et standby du port-group. Pour un réseau de production, prévoyez au minimum un chemin de secours lorsque l’architecture le permet. Simulez si possible la perte d’un uplink pendant une fenêtre de test et confirmez que le VMkernel reste joignable. Une redondance déclarée mais non testée peut masquer un mauvais trunk.
- Le réseau vMotion reste joignable après la perte d’un uplink prévu pour le failover.
Tester une migration vMotion pilote
Choisissez une VM non critique et lancez une migration Compute only entre deux hôtes. Vérifiez que la migration utilise le réseau vMotion et qu’elle se termine sans perte de service notable. Contrôlez les tâches vCenter et les logs si l’opération échoue. Ne généralisez pas avant d’avoir testé au moins une migration dans chaque zone réseau concernée.
- La VM pilote migre à chaud entre les hôtes avec succès.
Mesurer les performances et la saturation
Pendant la migration, observez l’utilisation des pNIC et la durée. Un lien 1 Gb peut fonctionner mais devenir limitant avec plusieurs migrations simultanées ou des VM très mémoire. Ajustez le nombre de migrations parallèles ou la capacité réseau selon les besoins. Évitez que vMotion ne sature un lien partagé avec le stockage.
esxtop- La migration n’entraîne pas de saturation durable ni de perte sur les autres trafics.
Documenter et répliquer la configuration
Consignez VLAN, sous-réseau, IP VMkernel, MTU, port-group et uplinks. Sur un cluster, comparez tous les hôtes afin d’éviter un nœud dont le port-group diffère. Ajoutez la vérification vMotion aux contrôles post-maintenance des switches ou des cartes réseau.
- Tous les hôtes du périmètre possèdent une configuration vMotion cohérente et documentée.
Validation
La procédure est validée lorsque :
- Chaque hôte possède un VMkernel vMotion sur le réseau prévu.
- vmkping réussit entre les interfaces vMotion avec la MTU configurée.
- Les uplinks et trunks sont cohérents et le failover réseau est testé.
- Une migration vMotion pilote se termine correctement sans utiliser un réseau inattendu.
Retour arrière
- Désactiver le service vMotion sur le nouveau VMkernel si le réseau n’est pas stable.
- Supprimer le VMkernel et le port-group uniquement après avoir vérifié qu’aucune migration ou autre service ne les utilise.
- Retirer le VLAN des trunks dans l’ordre inverse après retour à l’ancien réseau.
- Restaurer la configuration vSwitch/dvSwitch et uplinks documentée avant l’intervention.
Dépannage / erreurs fréquentes
- vmkping échoue : vérifier VLAN, trunk, IP, masque, route VMkernel et pare-feu intermédiaire.
- Ping standard OK mais jumbo KO : MTU incohérente sur un élément du chemin.
- Migration échoue alors que le réseau est joignable : vérifier service vMotion activé, compatibilité hôtes et logs vCenter/ESXi.
- Débit faible : contrôler pNIC, duplex, saturation et partage du lien avec stockage/management.
- Un hôte seulement échoue : comparer son port-group, VLAN, uplink et VMkernel aux hôtes fonctionnels.