Migrer de Hyper-V vers Proxmox VE

Toutes les migrations vers Proxmox ne partent pas de VMware. De plus en plus d’équipes quittent Hyper-V, souvent pour des raisons de coût de licence, de dépendance stratégique à Microsoft et de volonté de reprendre la main sur leur plateforme de virtualisation. La cible est la même que pour les sorties de VMware : Proxmox VE, un hyperviseur open source sans licence par cœur ni par VM. Ce guide décrit une migration Hyper-V vers Proxmox VE pensée pour ne pas interrompre vos services.

Pourquoi les équipes quittent Hyper-V

Hyper-V n’est pas un mauvais hyperviseur. Le problème est ailleurs. La fonction est liée à Windows Server : votre droit d’exécuter des machines virtuelles dépend des licences Windows Server (Standard ou Datacenter) et, bien souvent, d’un contrat Software Assurance. L’exploitation à l’échelle passe par System Center, une brique supplémentaire à licencier et à maintenir. Et la trajectoire produit de Microsoft pousse régulièrement vers Azure, ce qui ne correspond pas à toutes les stratégies, en particulier quand la souveraineté et la maîtrise des coûts comptent.

Proxmox VE répond à ces trois points. Le logiciel est open source : pas de licence par cœur ni par VM. Une souscription par socket, qui finance le développement de Proxmox et donne accès au dépôt entreprise stable et au support, remplace l’empilement de licences Windows Server et System Center pour une fraction du coût. L’exploitation reste entre vos mains, sur votre matériel ou chez l’hébergeur de votre choix.

Auditer avant de migrer

Comme pour toute migration, la phase d’audit fait la différence. Avant de toucher à quoi que ce soit, inventoriez votre parc Hyper-V :

• Chaque VM : vCPU, RAM, taille des disques VHDX, OS invité, criticité.
• La génération : VM de génération 1 (BIOS) ou génération 2 (UEFI, parfois avec Secure Boot). Ce détail conditionne le démarrage côté Proxmox.
• Les dépendances : quelles VMs communiquent entre elles, et lesquelles ne tolèrent aucune interruption.
• Le réseau : commutateurs virtuels, VLANs, cartes réseau virtuelles, règles de pare-feu.
• Le stockage : volumes, capacité totale, profil d’IOPS, présence de points de contrôle (checkpoints) à fusionner avant migration.

Cet inventaire indique comment dimensionner le cluster Proxmox VE et dans quel ordre migrer. Commencez par les VMs les moins risquées.

Préparer les VMs côté Hyper-V

Deux opérations se font tant que la VM tourne encore sous Hyper-V, et elles évitent la majorité des incidents de bascule.

D’abord, fusionnez les points de contrôle. Une VM avec une chaîne de checkpoints n’a pas un seul disque propre mais une pile de fichiers différentiels. Supprimez ou fusionnez ces points de contrôle pour obtenir un VHDX unique et cohérent à convertir.

Ensuite, retirez les services d’intégration Hyper-V sur les invités Windows et préparez le terrain pour les pilotes paravirtualisés VirtIO que Proxmox utilise. Ce travail fait avant la bascule épargne des démarrages en écran bleu après la migration.

Convertir les disques

Le cœur technique de la migration est la conversion du disque. Hyper-V stocke ses disques au format VHDX. Proxmox VE travaille en qcow2 ou en raw. L’outil qemu-img convertit un VHDX en qcow2 ou en raw en une commande, puis vous attachez le disque converti à une nouvelle VM Proxmox dont vous reproduisez la configuration matérielle relevée pendant l’audit.

C’est une migration à froid : la VM est arrêtée pendant la copie et la conversion. La fenêtre de coupure dépend de la taille du disque et du débit de votre stockage. C’est pourquoi l’ordre de passage et le regroupement par dépendance comptent autant.

Le cas des invités Windows

La plupart des parcs Hyper-V sont majoritairement Windows. Trois points méritent une attention particulière :

• Pilotes VirtIO : installez-les pour que la VM bénéficie d’un disque et d’un réseau paravirtualisés performants. Préparez l’installation tant que la VM tourne encore, et finalisez-la au premier démarrage sous Proxmox.
• Mode de démarrage : une VM de génération 2 attend de l’UEFI. Configurez la VM Proxmox en conséquence (OVMF), sinon elle ne démarrera pas. Si Secure Boot était actif, prévoyez de le gérer ou de le désactiver le temps de la bascule.
• Activation Windows : le changement de plateforme matérielle peut demander une réactivation. Anticipez-le pour les serveurs critiques.

Basculer et valider

Pour chaque VM migrée, validez avant de la déclarer terminée : elle démarre, le réseau répond, l’application fonctionne, et les performances correspondent à la base mesurée pendant l’audit. Conservez le VHDX d’origine jusqu’à validation. C’est votre retour arrière.

Migrez par vagues, groupées par dépendance. Les VMs critiques passent en dernier, une fois le processus éprouvé sur le reste du parc.

Là où ça devient difficile

La mécanique de conversion est bien documentée. Le plus dur, c’est de mener la migration sans rupture de service : fusionner proprement les checkpoints, gérer les invités de génération 2 et Secure Boot, séquencer les dépendances, et dimensionner le cluster cible pour ne pas migrer vers une plateforme fragile.

C’est le travail que prend en charge notre accompagnement à la migration Proxmox. Nous auditons le parc Hyper-V existant, dimensionnons et construisons le cluster Proxmox VE, menons la migration par vagues et validons chacune. Vous réduisez votre dépendance aux licences Windows Server sans porter vous-même le risque de la migration. Une fois la migration faite, vous exploitez le cluster vous-même ou vous le confiez en hébergement Proxmox managé.