Hyper-V WS2025 : le piège qui casse tes migrations à chaud

Tu mets à jour un hôte Hyper-V vers Windows Server 2025, tout semblait aller bien pendant les tests, et puis la première migration à chaud en production plante avec un message 0x8009030E ou 0x8009030D. Rien n’a changé dans ta configuration Hyper-V. Le coupable, c’est Credential Guard, activé par défaut depuis cette version — et ce n’est qu’un des changements qui méritent ton attention avant de généraliser la mise à jour sur un cluster de production.

Windows Server 2025 apporte de vraies nouveautés pour Hyper-V : le partitionnement GPU gagne enfin la migration à chaud, les clusters sans Active Directory peuvent migrer leurs VM sans passer par une migration rapide, et les limites d’échelle doublent sur plusieurs points. On passe en revue ce qui change concrètement, avec les chiffres exacts, et surtout comment éviter le piège de la migration qui casse après l’upgrade.

Hyper-V change d’échelle

Le tableau des maximums documenté par Microsoft donne une idée claire de l’ampleur du bond entre Windows Server 2022 et 2025. Côté hôte, le nombre de processeurs logiques passe de 1 024 à 2 048, tout comme les processeurs virtuels disponibles pour la partition racine. Côté VM, une machine virtuelle de génération 2 peut désormais utiliser jusqu’à 2 048 processeurs virtuels (contre 1 024 auparavant), avec jusqu’à 240 To de mémoire. Le nombre de VM actives par serveur reste plafonné à 1 024, et un cluster peut toujours héberger jusqu’à 64 nœuds et 8 000 VM en exécution.

Ces chiffres ne concernent qu’une poignée d’environnements — peu de clusters tournent déjà à 1 024 processeurs logiques par hôte. Mais si tu gères des VM dédiées au calcul intensif ou à l’IA, qui réclament souvent des dizaines voire des centaines de vCPU par instance, cette marge de manœuvre change ce qui devient possible sans sharding applicatif.

Le partitionnement GPU gagne la migration à chaud

Avant Windows Server 2025, partager un GPU physique entre plusieurs VM obligeait à choisir entre l’assignation exclusive (Discrete Device Assignment, DDA) et l’absence totale de migration à chaud. Le GPU Partitioning (GPU-P) change ça : chaque VM reçoit une fraction dédiée du GPU via l’interface SR-IOV, et depuis cette version, tu peux déplacer ces VM d’un hôte à un autre sans interruption.

Quelques points à vérifier avant de t’y lancer :

• la migration planifiée fonctionne entre hôtes autonomes dès Windows Server 2025 Standard ; pour la haute disponibilité en cluster (bascule automatique en cas de panne non planifiée), il te faut l’édition Datacenter ;
• le GPU doit être identique — même fabricant, même modèle, même taille — sur tous les serveurs du cluster, et les pilotes doivent être installés partout à l’identique ;
• tu ne peux assigner qu’une seule partition GPU par VM, et l’allocation se fait automatiquement — impossible de choisir une partition précise ;
• pendant la migration, Hyper-V bascule automatiquement sur TCP/IP avec compression, ce qui augmente la charge CPU de l’hôte et allonge la durée du transfert par rapport à une VM sans GPU partitionné.

Les GPU NVIDIA A2, A10, A16 et A40 sont pris en charge côté matériel, avec des invités Windows 10/11, Windows Server 2019/2022 ou Ubuntu 18.04/20.04 LTS. Pour les détails de configuration complets, la documentation officielle de Microsoft sur le partitionnement GPU liste les prérequis matériels et logiciels.

Live migration sans Active Directory : enfin possible

Les clusters workgroup — des clusters à basculement qui ne dépendent pas d’un contrôleur de domaine — existent depuis Windows Server 2016. Mais jusqu’à présent, ils ne supportaient que la migration rapide (quick migration), avec une coupure de service le temps du transfert. Windows Server 2025 ajoute enfin la migration à chaud pour ces clusters.

Le mécanisme d’authentification repose sur des certificats PKU2U auto-signés plutôt que sur Kerberos : chaque nœud a besoin d’un compte local avec un nom d’utilisateur et un mot de passe identiques. Ça convient bien pour des scénarios où déployer une forêt AD complète ne se justifie pas — un site isolé, une DMZ, un labo. Le trafic de migration n’étant pas chiffré par défaut quel que soit le mode d’authentification, isole ce trafic sur un réseau dédié ou un VLAN si tu passes en production sur ce type de cluster.

Le piège qui casse tes migrations après la mise à niveau

C’est le point le plus susceptible de te surprendre en production. Depuis Windows Server 2025, Credential Guard est activé par défaut sur tous les serveurs joints à un domaine qui ne sont pas contrôleurs de domaine. Or la migration à chaud Hyper-V utilisait jusque-là CredSSP par défaut pour la délégation d’identité — et CredSSP ne fonctionne plus correctement avec Credential Guard activé, puisque ce dernier n’autorise que les identifiants fournis explicitement, pas les identifiants mis en cache ou SSO.

Concrètement : si l’hôte source d’une migration utilise CredSSP avec Credential Guard actif, la migration échoue — et ça touche aussi les outils qui s’appuient sur la migration à chaud en coulisses, comme SCVMM. Les erreurs typiques sont 0x8009030E (« No credentials are available in the security package ») et 0x8009030D (« The credentials supplied to the package were not recognized »).

La solution recommandée par Microsoft n’est pas de désactiver Credential Guard — ce serait renoncer à une protection réelle contre le vol d’identifiants — mais de basculer vers la délégation Kerberos contrainte (Kerberos Constrained Delegation), compatible avec Credential Guard :

1. dans Hyper-V Manager, Paramètres Hyper-V > Migrations en direct > Fonctionnalités avancées, sélectionne Kerberos comme protocole d’authentification ;
2. dans Active Directory, ouvre les propriétés de chaque compte ordinateur Hyper-V concerné, onglet Délégation, et configure « Faire confiance à cet ordinateur pour la délégation uniquement aux services spécifiés » en ajoutant CIFS et Microsoft Virtual System Migration Service pour chaque hôte partenaire ;
3. si des SPN manquent, enregistre-les avec setspn -s "Microsoft Virtual System Migration Service/" .

Teste ce basculement en préproduction avant de migrer un cluster entier vers Windows Server 2025 — le jour où tu découvres le problème ne doit pas être celui où tu as besoin de déplacer une VM en urgence. Le détail du problème et la procédure de contournement figurent dans la documentation Microsoft sur les problèmes connus de Credential Guard.

Et côté stockage

Deux évolutions moins spectaculaires méritent une mention. D’abord, un nouveau mécanisme de déduplication native ReFS, distinct de l’ancienne fonctionnalité Data Deduplication — les deux ne peuvent pas coexister sur le même volume. Cette dédup ReFS cible les charges actives (VDI, fichiers système), s’appuie sur le block cloning plutôt que sur un magasin de blocs séparé, et s’exécute de façon incrémentale plutôt qu’en réanalysant tout le volume à chaque passage. Ensuite, les performances NVMe sont annoncées en nette hausse par rapport à Windows Server 2022, avec un initiateur NVMe-over-Fabrics intégré pour le raccordement SAN.

Important à retenir avant de migrer un cluster existant

Tu ne peux pas ajouter un nœud Windows Server 2025 à un cluster Windows Server 2016 ou 2022 existant — le clustering mixte entre versions majeures n’est pas supporté. Il faut construire un nouveau cluster puis migrer les VM, par export/import, par migration à chaud « shared nothing » si les deux clusters coexistent temporairement sur le même domaine, ou par migration de stockage via SMB ou des volumes partagés de cluster.

FAQ

Faut-il l’édition Datacenter pour le partitionnement GPU ?

Pas pour la migration planifiée entre hôtes autonomes, qui fonctionne dès l’édition Standard. L’édition Datacenter devient nécessaire uniquement si tu veux la haute disponibilité en cluster, avec bascule automatique en cas de panne non planifiée.

La migration à chaud sans Active Directory est-elle aussi sécurisée que l’originale ?

L’authentification par certificats PKU2U remplace Kerberos de façon fonctionnellement correcte, mais le trafic de migration reste non chiffré par défaut, comme pour tout cluster Hyper-V. Isoler ce trafic sur un réseau dédié reste recommandé, encore plus en l’absence d’Active Directory pour contrôler les accès.

Dois-je désactiver Credential Guard pour corriger mes migrations qui échouent ?

Non — ce n’est pas la correction recommandée par Microsoft. Bascule plutôt vers la délégation Kerberos contrainte, qui est compatible avec Credential Guard et ne te fait pas perdre la protection contre le vol d’identifiants que cette fonctionnalité apporte.

Puis-je migrer mes VM existantes directement vers un cluster Windows Server 2025 ?

Pas en ajoutant les nouveaux nœuds à ton cluster actuel — le clustering mixte entre versions majeures n’est pas pris en charge. Construis un nouveau cluster Windows Server 2025, puis migre les VM par export/import, migration à chaud sans partage de stockage, ou migration de stockage, selon ton scénario.

Si Broadcom et les licences VMware t’ont déjà fait regarder Hyper-V de plus près, ces nouveautés valent le détour — mais planifie le test de la délégation Kerberos avant de toucher à un cluster de production. On a d’ailleurs détaillé comment trancher entre VMware, Hyper-V et Azure Local après la crise des licences Broadcom, et si c’est plutôt une migration depuis VMware que tu prépares, notre guide sur Nutanix Move 6.3 couvre un chemin de migration alternatif.