Migrez de VMware vers Hyper-V grâce à Windows Admin Center

Le rachat de VMware par Broadcom a agi comme un électrochoc. Aujourd’hui, la question n’est plus faut-il migrer? , mais comment migrer sans tout casser ou y perdre tous ses cheveux?. Entre les solutions tierces payantes et les méthodes manuelles risquées, Microsoft a discrètement sorti une arme redoutable : l’extension VM Conversion pour Windows Admin Center (WAC).

Après avoir testé l’outil encore en préversion, je voulais partager avec vous mon expérience. Et pour vous guider plus facilement dans cet article très long, voici des liens rapides :

Pourquoi quitter VMware ?

Le rachat de VMware par Broadcom a agi comme un électrochoc. Beaucoup de clients ont vu les coûts augmenter fortement après le rachat, car Broadcom a changé le modèle de licences (par exemple passage d’une licence perpétuelle à un modèle d’abonnement) et restructuré les offres. Certains ont reçu des renouvellements jusqu’à plusieurs fois plus chers qu’avant pour les mêmes besoins.

Ces changements rapides dans la structuration des produits, des bundles et du support ont créé de l’incertitude sur la roadmap et l’avenir des produits VMware, ce qui amène les DSI à repenser leurs choix technologiques à long terme

On retrouve d’ailleurs pas mal de blogueurs parlant de cet exode :

Qu’est-ce que Windows Admin Center ?

Présent depuis des années, Windows Admin Center (souvent abrégé WAC) est un outil d’administration web développé par Microsoft pour gérer des serveurs Windows, des clusters et des environnements hyperconvergés, depuis une interface moderne accessible via navigateur.

Concrètement, Windows Admin Center vous permet d’administrer, sans passer par du RDP, un grand nombre de services Microsoft :

  • Windows Server
  • Hyper-V
  • Clusters (Failover Clustering)
  • Machines virtuelles
  • Serveurs distants (on-prem ou Azure)
  • Stockage (Storage Spaces Direct)

Qu’est-ce que l’extension VM Conversion ?

C’est un nouvel outil Microsoft intégré à Windows Admin Center qui permet de migrer des machines virtuelles depuis VMware vCenter/ESXi vers Hyper-V, en mode agentless :

Actuellement, Il s’agit d’une extension prévue pour minimiser le temps d’arrêt grâce à la réplication en ligne des disques.

Attention, cette extension n’est pas pour but de migrer vers Azure Local. Un autre article déjà écrit il y a plusieurs mois traite de ce type de migration : de VMware à Azure Local.

Combien coûte VM Conversion ?

L’extension est actuellement en préversion. Son usage n’implique aucun coût de licence supplémentaire, mais pas non plus de support garanti par Microsoft.

Quelles versions d’OS sont supportées ?

Microsoft annonce une large liste sur la compatibilité :

  • Tous les vCenter VMware 6.x, 7.x et 8.x sont pris en charge
  • Côté OS invités :
    • Windows Server 2025, 2022, 2019, 2016, 2012 R2
    • Windows 10/11
    • Ubuntu 20.04, 24.04
    • Debian 11, 12
    • Alma Linux
    • CentOS
    • Red Hat Linux 9.0

L’extension fonctionne également dans un environnement Hyper-V en cluster (WSFC) : elle est cluster-aware et détecte correctement les nœuds et ressources.

Il supporte la migration de VM depuis ESXi vers des clusters Windows Server Failover (WSFC) sous Hyper-V. Vous pouvez donc distribuer les VM migrées sur plusieurs nœuds Hyper-V pour HA ou performances.

Quels sont les prérequis pour VM Conversion ?

  • Côté Windows Admin Center :
    • WAC en version au moins v2410 build 2.4.12.10 ou supérieure
    • PowerShell et PowerCLI installés
    • VMware VDDK version 8.0.3 installé
    • Visual Studio 2013 et 2015 installés
  • Côté Hyper-V :
    • le rôle Hyper-V doit être installé sur le (s) hôte (s) cible
    • Le compte utilisé durant le processus doit être administrateur local ou membre du groupe Hyper-V Administrators).
    • Si des VMs migrées sont sous Linux, les modules Hyper-V (hv_vmbus, hv_netvsc, hv_storvsc) et Linux Integration Services (hyperv-daemons ou linux-cloud-tools) doivent être pré-installés dans l’initramfs avant migration.

Combien de VM puis-je migrer simultanément ?

Jusqu’à 10 machines virtuelles par lot. On peut grouper ces machines selon leur dépendance applicative, leur placement dans un cluster ou même selon des critères métier (ex : séparer environnement de test/prod). Cela facilite les migrations massives par workload.

Comment l’outil VM Conversion marche ?

Microsoft explique bien les deux phases présentes dans l’outil VM Conversion :

Synchronisation : l’extension effectue une copie complète initiale des disques de la machine virtuelle pendant que la VM source continue de fonctionner. Cette phase minimise les temps d’arrêt en vous permettant de planifier la migration finale à un moment qui vous convient.

Migration : l’extension utilise la fonctionnalité Change Block Tracking (CBT) pour rechercher et répliquer uniquement les blocs modifiés depuis la dernière synchronisation. Pendant la transition, la machine virtuelle source est mise hors tension et une synchronisation delta finale capture toutes les modifications restantes avant d’importer la machine virtuelle dans Hyper-V.

Microsoft Learn

Quid du temps d’arrêt ?

Pendant la phase de synchronisation, la VM source continue de tourner, pendant qu’une copie initiale des disques est envoyée sur l’hôte Hyper-V, via la création d’un snapshot pour suivre les changements.

Au moment de la bascule, la VM source est arrêtée pour un dernier delta-sync avant import; ce processus réduit donc au minimum la fenêtre d’arrêt.

Que devient VMware Tools sur le VM migré ?

La présence de VMware Tools dans une VM sous Hyper-V peut provoquer des conflits de pilotes, donc il vaut mieux les retirer.

  • Initialement, il fallait supprimer les outils VMware Tools manuellement après la bascule vers Hyper-V.
  • Depuis la version 1.8.0, l’extension supprime automatiquement VMware Tools sur les VM Windows migrées en fin de processus.
  • Pour les VM Linux, il est recommandé de ne pas réinstaller open-vm-tools sur la cible Hyper-V (on s’appuie uniquement sur les pilotes Hyper-V ajoutés).

Et enfin, comme toujours, je vous propose dans la suite de cet article d’effectuer ensemble un pas à pas pour couvrir la migration de machines virtuelles hébergées sur VMware vers Hyper-V :

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser cet exercice dédié à la migration d’une machine virtuelle hébergée sur VMware vers Hyper-V via Windows Admin Center. Pour tout cela, j’ai utilisé :

  • Un environnement VMware
  • Un environnement Hyper-V
  • Une connexion réseau entre le réseau les deux hyperviseurs

Commençons par l’installation de Windows Admin Center sur une nouvelle machine hébergée sur VMware.

Etape I – Installation de Windows Admin Center :

Sur une machine virtuelle dédiée dans votre environnement VMware, téléchargez la dernière version de Windows Admin Center depuis la page officielle de Microsoft :

Choisissez l’installation avec l’option Express :

Dans cette démonstration, utilisez un certificat temporaire :

Lancez l’installation :

Une fois l’installation terminée, ouvrez la page de Windows Admin Center, puis authentifiez-vous avec votre compte :

Une fois connecté dans la console Windows Admin Center, attendez quelques minutes la fin de l’installation des extensions préinstallées :

Rendez vous dans les paramétrages dans WAC afin d’ajouter l’extension dédiée à la migration :

Etape II – Installation de prérequis WAC :

Comme indiqué dans la documentation Microsoft, certains prérequis doivent être installés sur la machine de Windows Admin Center.

Commencez par installer Visual C++ Redistributable Packages for Visual Studio 2013

Continuez en installant également Visual C++ 2015-2022 Redistributable 14.50.35719.0 :

Récupérez et décompressez VMware Virtual Disk Development Kit (VDDK), en version 8.0.3, dans le dossier WAC suivant :

Redémarrez ensuite votre machine virtuelle contenant Windows Admin Center.

Etape III – Connexion à Hyper-V depuis WAC :

Une fois la machine virtuelle WAC redémarrée, rouvrez la console, puis cliquez ici pour ajouter une connexion vers votre serveur Hyper-V :

Cliquez sur Ajouter :

Renseignez l’adresse IP de votre Hyper-V, les éléments d’identification, puis cliquez sur Ajouter :

La connexion est établie, cliquez dessus pour l’ouvrir :

Dans le menu de gauche, cherchez l’extension consacrée à la migration, cochez la case suivante pour installer PowerCLI, puis cliquez ici :

Attendez la fin de l’installation de PowerCLI :

Une fois l’installation terminée, cliquez ici ajouter une connexion à votre vCenter, renseignez vos informations de connexion, puis cliquez ici :

Une fois la connexion établie avec vCenter, les machines virtuelles s’afficheront :

Le protocole de test est maintenant en place. Commençons les tests par la migration d’une machine virtuelle fonctionnant sous Windows Server.

Etape IV – Test Windows : Synchronisation de la VM :

Toujours dans la liste des machines virtuelles, cochez sur une des VMs Windows disponibles, puis cliquez ici pour démarrer la synchronisation :

Renseignez le dossier de destination sur votre serveur Hyper-V, puis cliquez sur Synchroniser :

La phase de vérification préalable à la migration vient de démarrer (accessibilité, compatibilité matérielle, compatibilité OS, configuration réseau, …) :

La première copie des disques VMDK vers Hyper-V est en cours pour la création des fichiers VHDX par la suite :

Constatez d’ailleurs la création du dossier sur le serveur Hyper-V :

La migration passe en mode synchronisation différentielle afin de ne copier que les blocs modifiés depuis la synchronisation initiale, réduisant ainsi le volume de données à transférer avant le cutover :

Provisioning du disque cible Hyper-V (VHDX) : l’infrastructure prépare le stockage avant l’application des blocs synchronisés issus de la VM VMware :

Phase de delta sync : les blocs modifiés identifiés via CBT sont appliqués au disque Hyper-V afin d’aligner la VM cible avec l’état courant de la VM source :

Le monitoring de la carte réseau montre bien le transfert des données :

Synchronisation complète (100 %) : l’intégralité des données de la VM source est maintenant répliquée côté Hyper-V :

La VM cible est maintenant entièrement alignée avec la VM VMware et peut être basculée vers Hyper-V avec un dernier delta minimal.

Nous allons pouvoir procéder à la migration.

Etape V – Test Windows : Migration de la VM :

A ce stade, la machine virtuelle sous VMware est toujours allumée :

Testez le delta de migration en rajoutant sur votre machine virtuelle source de nouveaux fichiers :

Retournez ensuite sur Windows Admin Center afin de lancer la migration de celle-ci :

Choisissez ou non de désinstaller les outils VMware, puis cliquez ici :

Lancement de la migration : exécution des vérifications préalables avant bascule définitive vers la VM Hyper-V cible :

Vérifications pré-migration terminées : la synchronisation finale des blocs modifiés (delta sync) est en cours avant l’arrêt et la bascule de la VM :

Un snapshot est bien créé côté VMware :

Delta Sync en cours : application des derniers blocs modifiés afin d’aligner définitivement la VM cible avant le cutover final vers Hyper-V.

Arrêt de la VM source : la machine VMware est éteinte et la phase finale de synchronisation est lancée avant le démarrage côté Hyper-V :

La machine virtuelle est bien arrêtée côté VMware :

Migration terminée (100 %) : la VM cible Hyper-V est créée, synchronisée et prête à être démarrée en production :

La VM migrée s’exécute désormais sur Hyper-V, confirmant le succès du cutover depuis l’environnement VMware :

Windows détecte un arrêt inattendu lié au cutover, confirmant que la VM a bien été basculée depuis l’environnement VMware vers Hyper-V :


Erreur VMware Tools au premier démarrage : les anciens composants VMware, désormais incompatibles sous Hyper-V, doivent être désinstallés après la migration :

Désinstallez les VMware Tools devenus inutiles après le passage de la VM sous Hyper-V :

Les fichiers créés avant la commande Migrate sont bien présents après la bascule, confirmant l’intégrité de la synchronisation finale :

Notre serveur Windows a bien été migré depuis VMware vers Hyper-V avec succès. Testons maintenant la même opération avec un serveur Linux.

Etape VI – Test Linux : Synchronisation de la VM :

Exemple réalisé ici sur AlmaLinux / RHEL-like. Le but étant de :

  • Désinstaller VMware Tools
  • Installer composants Hyper-V
  • Recréer initramfs si nécessaire
  • Reboot

Pour cela créez une machine virtuelle Linux dont l’OS est compatible avec l’outil de Migration :

Avant la migration, ajoutez les pilotes Hyper-V à l’initramfs, reconstruction avec dracut, puis redémarrage pour assurer un démarrage correct sous Hyper-V.

echo 'add_drivers+=" hv_vmbus hv_storvsc hv_netvsc "' | sudo tee /etc/dracut.conf.d/hyperv.conf
sudo dracut -f --regenerate-all
sudo reboot

Toujours avant la migration, installez des services d’intégration Hyper-V (hyperv-daemons) afin d’optimiser les performances et l’interaction entre la VM Linux et l’hôte Hyper-V.

Exemple réalisé sur une distribution RHEL-like (AlmaLinux / Rocky / RHEL). (Adaptez la commande si vous êtes sur Ubuntu ou Debian) :

sudo dnf install hyperv-daemons -y

Vérifiez le chargement des modules Hyper-V (hv_*) dans le noyau Linux afin de confirmer la bonne prise en charge de l’environnement Hyper-V :

Toujours dans la liste des machines virtuelles, cochez sur une des VMs Linux disponibles, puis cliquez ici pour démarrer la synchronisation :

Renseignez le dossier de destination sur votre serveur Hyper-V, puis cliquez sur Synchroniser :

La phase de vérification préalable à la migration vient de démarrer (accessibilité, compatibilité matérielle, compatibilité OS, configuration réseau, …) :

La première copie des disques VMDK vers Hyper-V est en cours pour la création des fichiers VHDX par la suite :

Constatez d’ailleurs la création du dossier sur le serveur Hyper-V :

La migration passe en mode synchronisation différentielle afin de ne copier que les blocs modifiés depuis la synchronisation initiale, réduisant ainsi le volume de données à transférer avant le cutover :

Phase de delta sync : les blocs modifiés identifiés via CBT sont appliqués au disque Hyper-V afin d’aligner la VM cible avec l’état courant de la VM source :

Le monitoring de la carte réseau montre bien le transfert des données :

Synchronisation complète (100 %) : l’intégralité des données de la VM source est maintenant répliquée côté Hyper-V :

La VM cible est maintenant entièrement alignée avec la VM VMware et peut être basculée vers Hyper-V avec un dernier delta minimal.

Nous allons pouvoir procéder à la migration.

Etape VII – Test Linux : Migration de la VM :

Retournez ensuite sur Windows Admin Center afin de lancer la migration de celle-ci :

Lancement de la migration : exécution des vérifications préalables avant bascule définitive vers la VM Hyper-V cible :

Arrêt de la VM source : la machine VMware est éteinte et la phase finale de synchronisation est lancée avant le démarrage côté Hyper-V :

La machine virtuelle est bien arrêtée côté VMware :

Migration terminée (100 %) : la VM cible Hyper-V est créée, synchronisée et prête à être démarrée en production :

La VM migrée s’exécute désormais sur Hyper-V, confirmant le succès du cutover depuis l’environnement VMware :

Conclusion

La migration d’un environnement VMware vers Hyper-V n’est jamais une décision anodine. Elle est souvent motivée par des enjeux économiques, stratégiques ou organisationnels. Mais quelle qu’en soit la raison, elle doit rester avant tout une opération maîtrisée, structurée et techniquement fiable.

L’extension VM Conversion de Windows Admin Center n’est pas un simple assistant graphique. Elle propose une approche orchestrée et cohérente : synchronisation initiale, delta via CBT, puis phase de bascule contrôlée. Ce n’est pas “magique” et cela ne dispense pas d’une préparation sérieuse. En revanche, l’outil apporte un cadre clair qui simplifie fortement un processus historiquement complexe.

Dans mes tests, l’expérience s’est révélée stable et lisible. La gestion des clusters Hyper-V (WSFC), la logique de synchronisation progressive et l’interface unifiée dans WAC rendent la migration bien plus accessible qu’avec des méthodes artisanales. Cela reste une extension en preview, donc à évaluer sérieusement en environnement de test avant toute utilisation en production, mais la base technique est solide.

Ce qui est certain, c’est qu’une alternative crédible existe désormais pour les organisations qui souhaitent diversifier ou repositionner leur stratégie d’hyperviseur. La migration ne doit plus être perçue comme un saut dans l’inconnu, mais comme un projet structuré, pilotable et documenté.

de VMware à Azure Local

La migration des machines virtuelles depuis VMware vers Azure Local via l’outil Azure Migrate a récemment été annoncée en préversion. Cette nouveauté chez Microsoft représente une avancée significative dans les migrations automatisées vers le cloud hybride. Cette nouvelle fonctionnalité d’Azure Migrate permet donc aux organisations de transférer leurs charges de travail sur site vers une infrastructure Azure Local tout en minimisant les interruptions.

Depuis quelques déjà, il existe sur le marché d’autres solutions externes qui proposent la migration de machines virtuelles hébergées sur VMware vers un cluster Azure Local :

Azure nous facilite donc la chose en l’intégrant dans Azure Migrate. En parlant d’Azure Migrate, un premier article sous forme d’exercice est disponible juste ici. Il vous permet de tester la migration de machines virtuelles Hyper-V vers Azure :

De façon générale, voici quelqu’un des principaux avantages à utiliser Azure Migrate :

  • Aucune préparation requise : La migration ne nécessite pas l’installation d’agents sur les machines virtuelles hébergés sous Hyper-V ou VMware.
  • Contrôle via le portail Azure : Les utilisateurs peuvent gérer et suivre toutes les étapes de leur migration directement depuis le portail Azure.
  • Flux de données local : Les données restent sur site pendant la migration, ce qui réduit les risques de latence.
  • Temps d’arrêt minimal : La solution permet de migrer les VMs avec un impact minimal sur les opérations en cours.

Aujourd’hui, nous sommes ravis d’annoncer l’avant-première publique de la fonctionnalité Azure Migrate permettant de migrer des machines virtuelles de VMware vers Azure Local, une amélioration significative de nos capacités de migration vers le cloud qui s’étend de manière transparente jusqu’à la périphérie, conformément à notre approche du cloud adaptatif.

Microsoft Tech Community

L’écran ci-dessous nous montre la section dédiée à la migration de ressources vers Azure Local :

Comment se passe la migration VMware -> Azure Local ?

Les grandes étapes d’une migration vers Azure Local sont très proches de celles vers Azure. Quelques étapes et composants nécessaires différent légèrement :

  • Un projet doit toujours être créé via Azure Migrate depuis le portail Azure
  • 2 appliances (VMware et Azure Local) doivent être créées et configurées
    • Une appliance virtuelle s’exécutant sur les serveurs VMware
    • Une seconde appliance virtuelle s’exécutant sur le cluster Azure Local

Voici les principales phases du processus de migration Azure Migrate :

Phase de migrationDescription
1. PréparationPréparez-vous à migrer en complétant les prérequis. Déployez et configurez votre cluster Azure Local. Créez un projet Azure Migrate et un compte de stockage Azure.
2. DécouverteCréez et configurez une appliance source Azure Migrate sur VMware pour découvrir vos serveurs.
3. RéplicationConfigurez l’appliance cible sur Azure Local et sélectionnez les VMs à répliquer.
4. Migration et vérificationMigrez les VMs vers Azure Local et vérifiez leur bon fonctionnement après la migration.

Quels sont les systèmes d’exploitation pris en charge ?

Pour que cette migration puisse fonctionner, seulement certaines versions d’OS sont actuellement prises en charge :

ComposantSystèmes d’exploitation pris en charge
Environnement VMware sourceVMware vCenter Server version 8.0
VMware vCenter Server version 7.0
VMware vCenter Server version 6.7

VMware vCenter Server version 6.5
Appliance VMware Windows Server 2022
Environnement Azure Local cibleAzure Local, version 23H2
Appliance Azure LocalWindows Server 2022
Machine virtuelle invitée (Windows)Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2008 R2*
Machine virtuelle invitée (Linux)Red Hat Linux 6.x, 7.x
Ubuntu Server et Pro. 18.x
CentOS 7.x
SUSE Linux Enterprise 12.x
Debian 9.x

Microsoft liste toutes les conditions requises pour envisager cette migration juste ici.

Puis-je créer mon projet Azure Migrate dans toutes les géographies Azure ?

Pour le moment, les métadonnées de votre projet Azure Migrate peuvent être uniquement stockées dans une des géographies Azure suivantes pour les migrations vers Azure Local :

GéographiesRégions
Asie-PacifiqueAsie Sud-Est, Asie Est
EuropeEurope Nord – Europe Ouest
États-UnisUSA Centre, USA Ouest2

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser cet exercice dédié à la migration d’une machine virtuelle hébergée sur VMware vers Azure Local via Azure Migrate. Pour tout cela, il nous faut :

  • Un tenant Microsoft
  • Une souscription Azure active
  • Un environnement Azure Local opérationnel
  • Un environnement VMware opérationnel

Commençons par la création du projet sur Azure Migrate, puis la configuration de l’appliance sur l’environnement VMware.

Etape I – Configuration VMware :

Pour cela, recherchez le service Azure Migrate grâce à la barre de recherche présente dans votre portail Azure :

Sélectionnez le menu suivant, puis cliquez-ici pour créer votre projet de migration :

Renseignez les différentes informations de votre projet en prenant en compte les géographies supportant ce scénario de migration, puis cliquez sur Créer :

Une fois le projet créé, cliquez-ici afin d’installer une appliance sur l’environnement VMware :

Définissez la cible de migration comme étant sur Azure Local, puis la source comme étant VMware :

Nommez votre appliance VMware, puis cliquez ici pour générer une clef d’association (entre l’appliance et votre projet d’Azure Migrate) :

Une fois la clef générée, copiez la dans votre bloc-notes :

Lancez le téléchargement de votre appliance afin de pouvoir en disposer par la suite sur votre environnement VMware :

Afin d’y accéder plus facilement sur vSphere, vous pouvez créer un compte de stockage publique :

Dans ce compte de stockage, créez un conteneur blob :

Une fois l’image de l’appliance téléchargée localement, utilisez l’outil azcopy afin de déposer votre image OVA sur votre compte de stockage blob :

Vérifiez la présence de l’image OVA sur votre compte de stockage, puis cliquez dessus :

Récupérez l’URL blob de votre image OVA accessible publiquement :

Depuis votre console vSphere, cliquez-ici pour créer une nouvelle machine virtuelle via la fonction de template OVF :

Collez l’URL de votre image OVA, puis cliquez sur Suivant :

Confirmez votre confiance en cliquant sur Oui :

Nommez votre machine virtuelle appliance, ainsi que son dossier, puis cliquez sur Suivant :

Sélectionnez la ressource de calcul VMware adéquate, cochez la case de démarrage après création, puis cliquez sur Suivant :

Vérifiez toutes les informations dont l’OS utilisé par l’appliance VMware, puis cliquez sur Suivant :

Définissez la ressource de stockage VMware adéquate, puis cliquez sur Suivant :

Choisissez le réseau virtuel VMware adéquat, puis cliquez sur Suivant :

Vérifiez toutes les informations avant la création de la machine virtuelle, puis cliquez sur Finir :

Constatez la création de 2 tâches, puis attendez quelques minutes :

  • vSphere VMware rapatrie l’image OVA,
  • vSphere créé la machine virtuelle appliance

Une fois la VM créée, installez-y les outils VMware :

Cliquez sur Mettre à jour :

Une fois la VM démarrée, ouvrez la console web de celle-ci :

Attendez la finalisation de la préparation de Windows Server :

Acceptez les Termes et conditions :

Configurez le mot de passe du compte administrateur (clavier US), puis cliquez sur Finaliser :

Connectez-vous avec le mot de passe configuré juste avant :

Attendez quelques minutes pour voir automatiquement s’ouvrir le navigateur internet :

Acceptez les Termes et conditions d’Azure Migrate :

Laissez faire la connexion entre votre appliance VMware et Azure :

Collez la clef de votre projet Azure Migrate, puis cliquez sur Vérifier :

Une fois vérifiée, attendez quelques minutes pour constater d’éventuelles mises à jour de l’appliance VMware :

Rafraîchissez la page au besoin si le système vous le demande :

Authentifiez-vous avec votre compte Azure :

Cliquez ici pour utiliser le mécanisme d’authentification Azure PowerShell pour l’appliance VMware :

Collez le code donné précédemment, puis cliquez sur Suivant :

Choisissez le compte Azure aux droits RBAC adéquats :

Cliquez sur Continuer pour autoriser l’authentification Azure :

Fermez la fenêtre de navigation internet :

Attendez quelques minutes le temps de l’enrôlement de l’appliance VMware dans Azure Migrate :

Comme indiqué récupérez l’applicatif VMware Virtual Disk Developpement Kit depuis une source internet, copiez le dossier, puis cliquez sur Vérifier :

Afin que l’appliance VMware puisse découvrir les machines virtuelles en fonctionnement sur vCenter, cliquez-ici pour ajouter les informations d’identification :

Cliquez ici pour ajouter des informations sur les VMs hébergées sur VMware à analyser :

Vérifiez que la validation s’est effectuée avec succès :

Comme nous n’avons pas besoin d’effectuer d’analyse d’applications particulières, désactivez cette fonction :

Cliquez ici pour démarrer la découverte des machines virtuelles sur VMware :

Mais, avant de retourner sur Azure, n’oubliez pas de renseigner et de valider les informations d’identification de votre cluster Azure Local :

La découverte est terminée et les résultats sont disponibles sur Azure :

Retournez sur le portail Azure afin de rafraîchir la page de votre projet Azure Migrate :

Quelques rafraîchissements plus tard, les serveurs VMware commencent à faire leur apparition :

La configuration VMware est maintenant terminée, nous allons pouvoir nous concentrer sur la seconde partie de la configuration dédiée à Azure Local.

Etape II – Configuration Azure Local :

Toujours sur votre projet Azure Migrate, cliquez alors sur le bouton Répliquer :

Renseignez les informations suivantes, puis cliquez sur Continuer :

  • Sélectionnez le type de service : Serveurs ou machines virtuelles (VM)
  • Sélectionnez la destination : Azure Local
  • Sélectionnez la source : VMware vSphere
  • Pour l’appliance Azure Migrate : l’appliance créée sur votre vCenter

Renseignez les informations de votre cluster Azure Local, puis cliquez sur Suivant :

Indiquez un nom pour l’appliance Azure Local, générez la clé, puis copiez cette dernière dans un bloc note :

Télécharger le fichier ZIP de votre appliance Azure Local :

À l’aide d’Hyper-V Manager, créez une nouvelle VM sous Windows Server 2022, avec 80 Go (min) de stockage sur disque, 16 Go (min) de mémoire et 8 processeurs virtuels sur un de vos nœuds Azure Local, puis démarrez celle-ci :

Une fois authentifié en mode administrateur sur cette appliance Azure Local, copiez et collez le fichier zip téléchargé.

En tant qu’administrateur, exécutez le script PowerShell suivant à partir des fichiers extraits pour installer l’appliance Azure Local :

Set-ExecutionPolicy -ExecutionPolicy Unrestricted
.\AzureMigrateInstaller.ps1

Choisissez l’option 4 :

Choisissez l’option 1 :

Choisissez l’option 1 :

Confirmez votre action avec Y :

Attendez quelques minutes la fin du traitement :

Confirmez votre action avec l’option A :

Confirmez votre action avec N :

Redémarrez la VM, reconnectez-vous avec le même compte administrateur, ouvrez Azure Migrate Target Appliance Configuration Manager à partir du raccourci du bureau, puis collez la clef précédemment copiée :

Attendez quelques minutes le temps de l’enrôlement de l’appliance Azure Local dans votre projet Azure Migrate, puis authentifiez-vous via Azure PowerShell :

Une fois l’appliance Azure Local enregistrée, sous Gérer les informations du cluster Azure Local, sélectionnez Ajouter des informations de cluster, puis cliquez sur Configurer :

Attendez quelques minutes la fin de la configuration :

Retournez sur le projet Azure Migrate depuis le portail Azure, puis cliquez-ici :

Constatez l’apparition l’appliance Azure Local, puis cliquez sur Suivant :

Choisissez la machine virtuelle à migrer sur votre cluster Azure Local, puis cliquez sur Suivant :

Définissez la configuration réseau et stockage de votre machine virtuelle migrée, puis cliquez sur Suivant :

Configurez le nombre de vCPU et la RAM, puis cliquez sur Suivant :

Sélectionnez les disques que vous souhaitez répliquer, puis cliquez sur Suivant :

Dans ce dernier onglet, assurez-vous que toutes les valeurs sont correctes, puis sélectionnez Répliquer :

Restez sur cette page jusqu’à la fin du processus (cela peut prendre 5 à 10 minutes). Si vous quittez cette page, les objets liés à la réplication ne seront pas entièrement créés, ce qui entraînera un échec de la réplication et, par la suite, de la migration.

Les 2 notifications Azure suivantes devraient alors s’afficher :

De retour sur votre projet Azure Migrate, vous pouvez suivre votre réplication depuis le menu suivant :

Une section dédiée à Azure Local est disponibles et affiche les réplications, les opérations et les événements, cliquez-ici pour avoir plus de détail sur la réplication en cours :

Les différentes étapes de réplication se suivent :

La progression via un pourcentage est même visible :

La phase finale de synchronisation des données arrive par la suite :

La prochaine étape consistera justement à faire la migration pour basculer notre VM vers Azure Local.

Etape III – Migration VMware -> Azure Local :

Une fois la réplication terminée, la machine virtuelle répliquée sur Azure Local est visible en cliquant ici :

Cliquez alors sur le statut de la machine virtuelle vous indiquant que la migration est prête :

Déclenchez la migration vers Azure Local en cliquant ici :

La notification Azure suivante apparaît alors :

Le travail de bascule planifiée est visible dans le menu suivant :

Les différentes étapes de migration vers Azure Local se suivent :

Rafraîchissez cette fenêtre plusieurs fois afin de constater le succès du processus :

Constatez l’apparition de la machine virtuelle migrée sur la page Azure de votre cluster Azure Local, puis cliquez dessus :

Copiez l’adresse IP privée de cette nouvelle machine virtuelle créée sous Azure Local :

Etape IV – Actions post-migration :

Dans mon scénario, j’ai utilisé une connexion Azure Virtual Desktop hébergé sur mon cluster Azure Local :

Une fois sur le réseau de votre Azure Local, ouvrez une connexion RDP vers l’adresse IP de votre machine virtuelle migrée :

Rentrez les identifiants de l’administrateur local, puis cliquez sur OK :

Constatez la bonne ouverture de session Windows sur votre machine virtuelle migrée :

Si la migration vous semble réussie, retournez sur votre projet Azure Migrate afin de déclarer la migration vers Azure Local comme étant complète :

Confirmez votre choix d’arrêt de réplication en cliquant sur Oui :

La notification Azure suivante apparaît alors :

L’action de Terminer la migration ne fera que nettoyer la réplication en supprimant le travail de suppression de l’élément protégé – cela n’affectera pas votre VM migrée.

Une fois la ressource migrée supprimée, elle est également supprimée de la vue Réplications. Vous verrez également le travail de migration de la VM disparaître de la vue Réplications :

Retournez sur la machine virtuelle sous Azure Local afin de finaliser l’intégration de cette VM dans l’hyperviseur Azure Local :

Il nous faut donc activer la gestion des invités pour la machines virtuelle migrée en y attachant l’ISO.

Pour cela, connectez-vous à un serveur Azure Local, puis exécutez la commande CLI suivante dans une fenêtre PowerShell sur la VM migrée pour laquelle l’agent invité doit être activé :

az stack-hci-vm update --name $vmName --resource-group $rgName --enable-vm-config-agent true

Affichez les informations de l’installeur de l’agent :

Installez l’ISO de l’agent invité sur la VM migrée comme suit :

$d=Get-Volume -FileSystemLabel mocguestagentprov;$p=Join-Path ($d.DriveLetter+':\') 'install.ps1';powershell $p

Activez la gestion de l’invité après que l’agent de l’invité a été installé de la manière suivante :

az stack-hci-vm update --name $vmName --resource-group $rgName --enable-agent true

Cette dernière étape n’a malheureusement pas fonctionné chez moi, comme l’indique encore le statut du management invité :

Le sujet est encore en discussion sur le forum Tech Community de Microsoft :

Nul doute que le souci va être corrigé sous peu ! Une page de résolution des problèmes a aussi été créée par Microsoft juste ici, ainsi qu’une FAQ.

Conclusion

En choisissant de migrer de VMware vers Azure Local, les entreprises s’engagent dans une transformation stratégique qui allie flexibilité et modernité.

Cette transition permet non seulement de consolider les ressources locales avec la puissance d’Azure, mais aussi de réduire les coûts opérationnels et de simplifier la gestion des infrastructures hybrides.