Début Octobre, lors du Partner Technology Summit (PTS) Nutanix, un partenaire m’a posé une question pertinente :

«Lors des migrations de VM Windows Server 2025, on a un souci de conservation d’adresse IP, quand est-ce que ce sera supporté ? “

Sur le moment, je n’avais pas la réponse. Après vérification et échanges techniques, voici le résultat de mes recherches et le workaround actuellement fonctionnel.

Nutanix Move est une solution de mobilité inter-hyperviseurs permettant de migrer des VMs et fichiers avec un temps d’arrêt minimal. (les règles NSX vers FSN depuis la version 6.0 !)

Move prend en charge de nombreux scénarios de migration, notamment :

  • VMware ESXi → AHV,
  • Microsoft Hyper-V → AHV,
  • AWS EC2 → AHV,
  • Microsoft Azure Cloud → AHV,
    ainsi que des flux croisés vers NC2 sur AWS ou Azure.

Move automatise l’installation des drivers VirtIO, copie la VM, et peut réaliser une configuration post-migration, dont la restauration de la connectivité réseau.

Cependant, la documentation officielle précise explicitement parmi les limitations connues :

“IP address retention for Windows if WMIC utility is not installed. For IP address retention to work, install WMIC.”

Autrement dit, si WMIC n’est pas présent sur le système source, Move désactive la rétention IP lors de la migration.

L’absence de VMIC déclenche une condition $noWMIC = True, qui désactive la restauration d’adresse IP après migration.

Extrait du script concerné :

#$noWMIC = $null -ne ($Global:NoWMICOSStrings | ? { $Global:OSInfo.Caption -match $_ })

Depuis Windows 10 21H1 et Windows Server 2025, Microsoft a retiré l’outil WMIC.exe du système par défaut.

Cette évolution renforce la sécurité et la compatibilité avec les environnements modernes, mais affecte encore certains outils tiers, comme Nutanix Move, qui s’appuient sur l’ancien exécutable pour collecter les informations réseau avant migration..

Si certaines applications ou scripts avancés utilisent encore WMIC, il est possible d’obtenir les mêmes résultats en interrogeant WMI par d’autres moyens. Microsoft recommande désormais d’utiliser PowerShell et ses cmdlets CIM/WMI (Get-CimInstance, Invoke-CimMethod, etc.), ou d’accéder directement à l’API COM WMI ou aux bibliothèques .NET (comme System.Management en C#) pour exécuter les requêtes dans le code.

Il serait donc logique que les futures versions de Nutanix Move adoptent une implémentation fondée sur PowerShell CIM/WMI, afin de restaurer durablement la fonctionnalité de rétention d’adresse IP sur Windows Server 2025.

Une méthode de contournement permet de restaurer la rétention IP statique en mode préparation manuelle (Manual Preparation Mode).
Cette approche est fonctionnelle à partir de Move 6.0.

Étapes :

  1. Installer temporairement la feature WMIC sur la VM Windows source.
    • Pour plus de détails sur la réactivation ou la réparation de WMIC et du service WMI, consultez la KB-6958 de Nutanix.
    • Vérifie la présence de WMIC : wmic os get caption
  2. Modifier le script de Move sur l’appliance.
    • Connexion SSH à la VM move.
    • srcagent-shell
    • Éditer le fichier correspondant :
      • VMware : /opt/xtract-vm/resources/uvm/win/esx_setup_uvm.ps1
      • Hyper-V : /opt/xtract-vm/resources/uvm/win/hyperv_setup_uvm.ps1
    • Commente ou supprime la ligne 321 : #$noWMIC = $null -ne ($Global:NoWMICOSStrings | ? { $Global:OSInfo.Caption -match $_ })
  3. Créer un plan de migration en Manual Preparation Mode.

Et si le partenaire qui m’a posé la question au PTS passe par ici :
je ne suis vraiment pas physionomiste, donc impossible de remettre un visage sur la discussion…
Mais j’espère que tu tomberas sur cet article, en attendant que la rétention d’adresse IP fasse officiellement son retour dans une prochaine release de Move.

Je vais tenter de détailler ici absolument toutes les étapes d’implémentation de la solution de déploiement d’ESX avec la fonctionnalité Auto Deploy de VMware.

Cette fonctionnalité n’est disponible que si vous avez le niveau de licence suffisant à minima VMware vSphere Enterprise Plus, de même que les autres fonctionnalités que nous allons utiliser plus loin comme Host Profiles ou les Distributed Switch.

Activation d’Auto Deploy :

Depuis le vCenter, j’active la fonctionnalité dans le menu Auto Deploy :

Ici, je sélectionne Activer Auto Deploy et Image Builder.

J’ai quelques nœuds Cisco à déployer. Pour l’exemple, je vais récupérer l’Offline Bundle depuis my.vmware.com comme d’habitude dans la partie Custom ISO pour les OEM.

Une fois le fichier téléchargé, choisir New Image Profiles et injecter l’Offine Bundle précédemment récupéré.

Vous pouvez aussi ajouter le dépôt par défaut VMware si votre vCenter peut y accéder :

L’url du dépôt est https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Ensuite, je télécharge le zip de configuration TFTP, il est disponible dans l’onglet Configure d’Auto Deploy puis Download TFTP ZIP FILE.

Pour le moment, c’est tout côté vCenter. Je vais passer aux autres éléments indispensables à savoir un DHCP et un serveur TFTP. Pour cet environnement, je vais utiliser un redhat 7.

Installation du serveur DHCP :

yum install -y dhcp

Je configure le service avec le fichier de configuration : /etc/dhcpd/dhcpd.conf .

Ici, j’ai un bail très court, car mon scope DHCP n’est pas très grand et je veux pouvoir enchaîner les installations.

Attention le fichier du boot file name correspond à la configuration choisie :

BIOS = undionly.kpxe.vmw-hardwired

EUFI = snponly64.efi.vmw-hardwired

EUFI + Secureboot = snponly64.efi.vmw-hardwired.officialkey

Je suis parti sur EUFI + Secureboot, car il désactive la fonctionnalité Secureboot si elle n’est pas disponible.

Je démarre le service et je l’active avec le système :

systemctl start dhcpd.service && systemctl enable dhcpd.service

Pour information, les baux du DHCP seront visibles dans /var/lib/dhcpd.dhcpd.leases.

Si besoin on autorise le service sur le firewall puis on recharge le service :

firewall-cmd --permanent --add-service={dhcp} 
firewall-cmd --reload

On passe ensuite au serveur TFTP :

J’installe le service tftp avec la commande :

yum install -y tftp-server

Comme pour les autres, je lance le service et je demande à ce qu’il démarre automatiquement avec le système :

systemctl start tftp.service && systemctl enable tftp.service

Jusqu’ici, j’ai réalisé les opérations en root, mais je vais avoir besoin d’utiliser un autre compte pour uploader les données sur le serveur et il sera beaucoup plus simple de passer par un accès ftp.

Installation optionnelle du server ftp :

yum install -y vsftpd

Il y a plusieurs modifications à effectuer pour démarrer correctement le service et le configurer selon les besoins. Il faut éditer le fichier /etc/vsftpd/vsftpd.conf

anonymous_enable=NO
listen=YES
listen_ipv6=NO
local_root=/var/lib/tftpboot

Comme pour les autres, j’active le service en auto et je le démarre :

systemctl enable vsftpd.service && systemctl start vsftpd.service 

/!\ Il faudra configurer les droits au besoin sur le dossier /var/lib/tftpboot avec la commande chmod.

Je peux enfin uploader via l’accès ftp le contenu du deploy-tftp.zip qui viendra se positionner dans /var/lib/tftpboot.

Comme moi, vous devriez avoir tous les fichiers à la racine de /var/lib/tftpboot :

Cela devrait être bon côté serveur linux. Si besoin pour vérifier l’état des services :

systemctl status dhcpd.service
systemctl status tftp.service
systemctl status vsftpd.service

Règle de déploiement :

Je vais ensuite créer une “deploy rule“. Alors ici, je vais en faire une plutôt générique pour l’exemple, mais je vais en faire des spécifiques pour chaque OEM que j’aurai dans mon scope HPE, Dell, Cisco, etc.

Pour cette règle, il faut choisir le host location, c’est-à-dire l’emplacement où ESX fraîchement déployé arrivera dans l’arborescence du vCenter.

Ensuite, je choisis le software dépôt et l’image ESX qui sera déployée.

Puis le host profile associé.

Rien de tel qu’une petit VM avec un ESXi nested pour tester rapidement le déploiement !

J’ai désactivé le secureboot dans les options de la VM, et c’est bien pris en compte ici :

Après quelques minutes, j’ai un ESXi :

Celui-ci a rejoint (en maintenance mode) le vCenter à la racine de l’emplacement précédemment spécifié.

Dans un prochain article, nous verrons la customisation et l’application du host profile qui viendra finaliser le setup de mon ESX afin qu’il soit prêt pour héberger des machines virtuelles.

La semaine prochaine aura lieu la conférence des utilisateurs VMware, ce n’est pas un événement réservé aux experts, mais bien l’occasion de découvrir de nouvelles solutions, ou d’apprendre des retours d’expériences clients qui seront présentés.

Pour cette journée, plusieurs membres de la communauté feront des retours d’expériences, nos sponsors feront la démonstration de produits liés à l’écosystème VMware, nous aurons aussi quelques têtes d’affiches avec Frank Denneman (Chief Technologist – Cloud Infrastructure chez VMware), Cormac Hogan (Director and Chief Technologist, VMware. Author and Blogger) et Niels Hagoort (Staff Technical Marketing Architect for VMware Cloud).

Dès 8h30 et pour toute la journée, le 6 octobre, retrouvez-nous à l’Étoile Business Center dans le 8e à Paris.

Ne ratez pas cette occasion de rencontrer vos pairs, l’inscription se passe ici -> https://www.vmugticketsemea.eu/france/

Les plus attentifs d’entre vous aurons noté que j’ai récemment fait un billet sur l’utilisation de l’outil certificate-manager en ligne de commande. Mais il s’avère que mon CSR n’avait pas le niveau de sécurité requis et je n’ai pas trouvé l’option pour modifier la taille de la clé.

il y a bien le fichier certool.cfg pour modifier la configuration mais rien ne semble documenter la longueur de la clé. J’aurai simplement pu générer ma demande avec openssl, mais j’avais la ferme intention d’utiliser les produits mis à disposition par VMware.

Je suis donc partie sur l’utilisation de la GUI pour réaliser l’opération car le changement de la taille de la clé y est accessible:

La génération du csr se passe très bien, mais les soucis apparaissent à l’importation:

En effet, l’assistant nous demande de lui fournir la clé privée générée lors de notre demande de csr, sauf qu’à aucun moment, il ne nous indique le chemin en question. Impossible de trouver le chemin dans la documentation officielle VMware.

C’est en parcourant d’autres blogs à la recherche du chemin que je suis tombé sur l’article de Bryan van Eeden : Where is my private key when using the vSphere UI? – vCloud Vision

Il y décrit, avec la même surprise que moi, la demande de la clé privée mal documenté, et indique la commande pour récupérer le précieux :

/usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store MACHINE_SSL_CERT --alias __MACHINE_CSR

Copier les informations avec —–BEGIN CERTIFICATE REQUEST—– et —–END CERTIFICATE REQUEST—– dans un fichier et vous pourrez l’utiliser pour l’importation, ou copier les directement dans le menu VMware dans la section Private Key :

Pour la section “Chain of trusted root certificates” copier les informations du certificat de l’autorité de certification ou de la chaine complète qui a signé la demande.

Après redémarrage des services, le certificat devrait correctement en place.

Si comme moi vous avez des appliances ZIA Virtual Service Edges à déployer sur des clusters VMware, vous aurez peut être un paramètre bien particulier à configurer pour éviter de recevoir les paquets réseau en double lorsque vous avez plusieurs interfaces physique sur votre vSwitch mais pas de LCAP pour le teaming.

Cette problématique est décrite dans la kb : Duplicate Multicast or Broadcast Packets are Received by a Virtual Machine When the Interface is Operating in Promiscuous Mode (59235) (vmware.com)

et dans la doc zscaler : Zscaler Help

Pour configurer la valeur

Get-VMHost votrenomESXici | Set-VMHostAdvancedConfiguration -Name "Net.ReversePathFwdCheckPromisc" -Value 1

Pour vérifier la valeur

Get-VMHost votrenomESXici | Get-VMHostAdvancedConfiguration -Name "Net.ReversePathFwdCheckPromisc"

Pour faire la modification sur tout un cluster par exemple

Get-Cluster votrenomCluster | Get-VMHost |Get-VMHostAdvancedConfiguration -Name "Net.ReversePathFwdCheckPromisc"