Que faire si une machine virtuelle Windows Server 2025 ne démarre pas sur AMD EPYC en 2026 ?

Votre VM Windows Server 2025 redémarre en boucle après une mise à jour de l’hôte, ou affiche une erreur de récupération au démarrage.

À faire : conservez un état récupérable, puis vérifiez séparément le micrologiciel, le contrôleur de disque, le type de processeur et les changements récents. À éviter : attribuer la panne à AMD EPYC ou à Proxmox VE 9.2 sans reproduction. Pour une VM de production, faites d’abord les essais sur une copie ou pendant une fenêtre de maintenance, avec un retour arrière défini.

Cet article est destiné aux administrateurs Proxmox et aux équipes MSP confrontés à un échec de démarrage de Windows Server 2025. Il s’adresse aussi aux équipes qui préparent une mise à niveau de l’hôte et veulent vérifier leurs VM avant de changer la production, ainsi qu’aux responsables IT qui évaluent un hôte dédié pour plusieurs machines virtuelles.

Dernière mise à jour : 27 octobre 2026. Les informations sur la version s’appuient sur l’annonce officielle de Proxmox VE 9.2, et les exigences système sur la documentation Microsoft consacrée au matériel requis pour Windows Server. Les rapports de panne évoqués ci-dessous sont des témoignages communautaires, pas une confirmation d’un défaut général.

Windows Server 2025 sur AMD EPYC : isoler l’incident avant d’accuser l’hôte

Un échec de démarrage n’indique pas à lui seul si l’incident se trouve dans l’hyperviseur, dans la configuration de la VM, dans le disque virtuel ou dans Windows. La première décision consiste donc à identifier la couche en panne et à éviter d’empiler des changements qui rendraient le diagnostic impossible.

Il faut distinguer trois situations :

• L’interface de gestion ou l’accès à l’hôte est indisponible. Vérifiez d’abord si l’hôte reste joignable par SSH et si d’autres VM fonctionnent. Une perte d’accès à la console d’administration n’est pas, en soi, une panne de démarrage Windows.
• La VM ne démarre pas ou s’arrête avant le chargement de Windows. Relevez l’état et les messages visibles dans Proxmox. La cause peut se situer dans la configuration de démarrage ou dans l’accès au disque virtuel.
• Windows atteint son environnement de récupération ou affiche une erreur interne. Le diagnostic se déplace vers le système invité, ses pilotes et son démarrage. Microsoft décrit les possibilités de dépannage du démarrage avec l’environnement de récupération Windows.

Consignez le code d’erreur exact, le dernier stade atteint, l’heure de l’incident et les changements récents de l’hôte ou de Windows. Si une seule mise à jour précède le problème, c’est une piste à tester, pas encore une preuve de causalité. Une mise à jour Windows et une mise à jour de l’hyperviseur installées dans la même fenêtre compliquent particulièrement l’attribution.

La version Proxmox VE 9.2 a été publiée le 21 mai 2026, selon l’annonce officielle. Proxmox y décrit une mise à jour qui comprend notamment un noyau par défaut et des composants de plateforme renouvelés. Cela donne un point de comparaison pertinent lorsque le symptôme survient après une mise à niveau, mais ne démontre pas que la mise à niveau est la cause de chaque panne. Vérifiez les détails de version dans l’annonce de publication et dans le guide d’administration Proxmox VE.

Des utilisateurs ont rapporté des difficultés de démarrage de Windows Server 2025 après une mise à jour de Proxmox VE 9.2 associée au noyau Linux 7.0, dans des configurations particulières. Vous pouvez consulter le rapport publié sur le forum communautaire Proxmox et une discussion sur des configurations Windows Server 2025 sous PVE 9.2. Ces pages fournissent des pistes à confronter à votre propre installation ; elles n’établissent ni une cause commune ni un correctif universel lié à AMD EPYC.

Avant la mise à niveau : préparer une copie et une sortie de secours

Ne commencez pas par modifier la VM. Préparez plutôt les éléments qui vous permettront de comparer l’état antérieur et l’état défaillant.

Relevez et conservez :

• la version de Proxmox VE et le noyau actif de l’hôte ;
• le système invité et les dernières mises à jour Windows installées ;
• la configuration complète de la VM, notamment le modèle de processeur, le micrologiciel, l’ordre de démarrage, le contrôleur et le disque virtuels ;
• la date, l’heure et la séquence des changements précédant l’incident ;
• les messages affichés pendant le démarrage et les journaux de l’hôte.

Sur l’hôte, ces commandes vous aident à consigner la version et l’état de la VM. Remplacez <VMID> par l’identifiant de votre machine virtuelle :

pveversion -v
uname -r
qm status <VMID>
qm config <VMID>

La sortie doit être conservée avec le dossier de changement. Les lignes de version indiquent les composants installés ; la configuration de la VM permet de comparer les valeurs avant et après la mise à niveau. Ces commandes ne prouvent pas que Windows fonctionne correctement : elles fournissent un état initial exploitable.

.warning — Avant toute opération susceptible de modifier l’hôte ou le disque invité, vérifiez qu’une sauvegarde existe et que vous connaissez le chemin de restauration. Une sauvegarde qui n’a jamais été restaurée n’est pas un retour arrière validé.

Si votre plan de sauvegarde utilise Proxmox Backup Server ou un stockage distinct, vérifiez le résultat du travail et réalisez un essai de restauration sans écraser la VM de production. Un contrôle de cohérence de sauvegarde ne remplace pas une validation du démarrage de Windows. Définissez par écrit qui autorise la reprise, qui peut interrompre la maintenance et quel résultat impose de revenir à l’état antérieur.

Pour une migration prévue vers Proxmox VE 9.2, commencez par une copie représentative de la VM et gardez la production inchangée jusqu’à la fin de l’essai. Le guide d’administration officiel décrit la gestion des VM et les opérations de sauvegarde ; adaptez la procédure à votre stockage réellement configuré. Pour les accès d’administration à l’hôte, vous pouvez aussi consulter le guide OSFP Cloud sur l’accès à un serveur par shell.

Étape suivante : vérifier le chemin de démarrage sans changer plusieurs paramètres

Une fois l’incident documenté et la copie récupérable, vérifiez la chaîne de démarrage dans l’ordre. L’objectif est de repérer ce qui a changé et de tester une seule hypothèse à la fois.

Première vérification : micrologiciel et entrée de démarrage. Dans la configuration de la VM, notez si le démarrage utilise SeaBIOS ou UEFI et comparez ce choix à la configuration qui fonctionnait auparavant. Vérifiez également l’ordre des périphériques de démarrage. Une entrée absente ou un changement de mode peut empêcher Windows de retrouver son chargeur, mais vous ne devez pas basculer le micrologiciel simplement parce que l’écran d’erreur apparaît.

Deuxième vérification : présence du disque virtuel. Confirmez que le disque attendu figure toujours dans la configuration et qu’il est présenté à la VM. Dans l’environnement de récupération Windows, observer le disque constitue un indice diagnostique ; cela ne démontre ni que le pilote du contrôleur est le bon, ni que toutes les lectures et écritures sont fiables.

Troisième vérification : contrôleur et pilote. Comparez le contrôleur configuré à celui utilisé lors de l’installation de Windows, ainsi qu’aux pilotes disponibles dans l’environnement de récupération. Si Windows ne voit pas le disque, recherchez d’abord une différence de contrôleur ou de pilote. Ne changez pas en même temps le type de contrôleur, l’ordre de démarrage et le micrologiciel : si le démarrage revient, vous ne saurez pas quel changement a résolu le symptôme.

Microsoft distingue les opérations de diagnostic et de récupération dans sa documentation sur les fonctionnalités de dépannage de WinRE. Employez l’environnement de récupération pour examiner la situation et appliquer une réparation adaptée au message relevé. Ne lancez pas une réparation qui écrit sur le disque de production sans avoir vérifié la sauvegarde et défini le retour arrière.

Pour comparer les paramètres, utilisez une liste de contrôle dans votre dossier de changement :

• Identique à l’état fonctionnel : conservez le réglage et passez au contrôle suivant.
• Différent, et la différence est datée du changement précédant la panne : testez cette différence seule sur une copie.
• Aucune différence claire ou résultat non reproductible : ne modifiez pas la production ; recueillez les journaux et poursuivez le diagnostic par couche.
• Le disque est visible, mais Windows reste en récupération : poursuivez l’examen du pilote, du chargeur et des messages WinRE ; ne concluez pas à un problème résolu sur le seul critère de visibilité.

Ensuite, comparer le processeur virtuel et les versions du noyau

Le fait que l’hôte utilise AMD EPYC ne prouve pas que le processeur est responsable de l’incident. Relevez le type de processeur attribué à la VM et comparez-le à la configuration antérieure. Vérifiez aussi le noyau actif sur l’hôte, puis recherchez les changements effectués depuis le dernier démarrage réussi.

Vous pouvez capturer les informations de l’hôte et de la VM avec les commandes suivantes :

uname -r
pveversion -v
qm config <VMID>
journalctl -k -b

Dans la dernière commande, les entrées du noyau du démarrage en cours peuvent aider à repérer des erreurs de périphérique ou des événements survenus au moment de l’incident. Elles ne remplacent pas les messages de la VM ni les informations fournies par WinRE. Conservez les sorties dans le même dossier que les codes d’erreur et les changements horodatés.

Procédez ensuite par comparaison :

• Si le type de processeur virtuel a changé, testez le retour à la valeur connue sur la copie, sans modifier en parallèle le contrôleur.
• Si le noyau de l’hôte a changé, consignez la version courante et la version antérieure avant d’envisager un retour. Vérifiez d’abord les notes officielles et les dépendances de l’hôte.
• Si l’incident suit une mise à jour Windows, vérifiez les messages de récupération et l’historique de mise à jour avant d’attribuer le problème à Proxmox.
• Si la panne ne se reproduit pas sur la copie ou n’est liée à aucun changement identifiable, ne transformez pas une corrélation temporelle en diagnostic.

.warning — Changer le type de processeur ou démarrer sur un autre noyau peut modifier le comportement de plusieurs VM. Ne faites ces essais qu’avec un plan de retour, une copie testée et une fenêtre de maintenance approuvée. Le retour à un ancien noyau observé dans un témoignage communautaire n’est pas, à lui seul, une consigne officielle applicable à tous les hôtes.

Le modèle de processeur virtuel peut influencer les instructions exposées à Windows et la compatibilité de la VM, mais ne modifiez pas sa valeur au hasard. Si le problème apparaît uniquement après un changement de modèle et peut être reproduit sur la copie, documentez précisément les deux états avant d’envisager une correction de production.

En fenêtre de maintenance : appliquer la correction testée et mesurer la reprise

Une réparation n’est justifiée que lorsque votre essai relie le symptôme à une différence précise. Si le test indique que le changement de micrologiciel, de contrôleur, de processeur virtuel ou de noyau est associé à l’échec, restaurez uniquement la valeur précédente et vérifiez le résultat. Si le lien n’est pas reproductible, conservez l’état de production et réduisez encore le nombre d’hypothèses.

Pendant la maintenance :

• confirmez que la sauvegarde peut être restaurée et que les personnes responsables sont disponibles ;
• appliquez un seul changement réversible à la fois sur la copie, puis notez son résultat ;
• si le test fonctionne, reproduisez cette modification unique en production conformément au plan approuvé ;
• si le démarrage échoue ou si un autre symptôme apparaît, arrêtez les modifications et appliquez le retour arrière défini ;
• conservez la configuration avant et après l’intervention, avec les messages observés.

Après le retour à un démarrage normal, vérifiez le chargement complet de Windows, la détection des périphériques, les services essentiels et le fonctionnement des applications dépendantes. Effectuez un redémarrage contrôlé et observez si le problème revient. Le démarrage ponctuel du système ne valide ni la stabilité après redémarrage ni la disponibilité des services métiers.

La validation doit s’appuyer sur des critères définis avant la maintenance : démarrage terminé, services attendus disponibles, absence d’une erreur connue et accès applicatif rétabli. Si un critère échoue, n’élargissez pas la modification en urgence ; revenez à l’état antérieur et gardez les journaux pour une analyse complémentaire.

Pour toute VM importante, prévoyez une responsabilité claire sur la sauvegarde, la restauration et la décision de reprise. La méthode de vérification doit inclure la restauration d’une copie isolée, sans remplacer la VM active. Définissez également qui peut suspendre l’intervention et quel seuil d’erreur impose de revenir immédiatement à la configuration précédente.

De la VM validée au choix de l’hôte : raisonner par charge, pas par démarrage

Une VM Windows qui démarre correctement ne suffit pas à déterminer combien de VM un hôte pourra supporter. Le dimensionnement dépend des usages simultanés, de la mémoire réellement attribuée, des pointes CPU, des entrées-sorties de stockage, des licences et de la capacité de restauration. Une VM de test, un serveur de fichiers et une application métier n’ont pas nécessairement les mêmes profils de consommation.

Pour structurer le choix, demandez-vous :

• Si la charge est temporaire, légère ou très variable, une VM partagée peut rester plus adaptée qu’un serveur dédié, notamment si vous n’avez pas besoin de contrôler le matériel ou de maintenir un environnement en continu.
• Si plusieurs VM doivent partager un hôte stable avec une allocation maîtrisée, évaluez les ressources sur un scénario représentatif et mesurez les pointes avant de fixer les allocations.
• Si les disques et la reprise sont prioritaires, définissez d’abord la disposition de stockage, la redondance et les sauvegardes externes. La configuration des disques physiques ne remplace pas un plan de restauration. Le guide OSFP Cloud sur les choix de mémoire et de disques peut vous aider à préciser ces besoins.
• Si Windows Server est destiné à la production, vérifiez le mode de licence applicable à votre usage et à votre environnement, au lieu d’inférer la conformité à partir d’un simple démarrage réussi. Pour poursuivre ce contrôle, consultez le guide OSFP Cloud sur la vérification des licences Windows Server 2025.

La fiche des offres OSFP Cloud indique des serveurs AMD EPYC 7543P avec 32 cœurs et 64 threads, des options de 128 Go ou 256 Go de mémoire, ainsi que des disques NVMe configurables ; elle indique également la disponibilité de Proxmox VE et de plusieurs éditions de Windows Server. Vérifiez les options et leurs conditions sur la page des offres OSFP Cloud avant de planifier une migration : une configuration de stockage, une licence ou une option non affichée ne doit pas être présumée disponible.

Un serveur physique dédié peut être pertinent si vous avez besoin d’un hôte réservé à vos VM, d’une allocation matérielle que vous contrôlez et d’un environnement durable. À l’inverse, si votre charge est ponctuelle, très faible ou dépend d’une élasticité immédiate, une infrastructure partagée peut mieux correspondre à votre besoin. Une VM partagée peut aussi subir la concurrence de ressources, limiter le contrôle sur le matériel sous-jacent ou rendre certains choix de stockage et de système moins flexibles. Si ces limites deviennent déterminantes pour vos machines Windows, examinez les options de location de serveur AMD EPYC d’OSFP Cloud en vérifiant la configuration réellement proposée, plutôt qu’en supposant que toute panne de démarrage appelle un changement d’hôte.

Questions de dépannage fréquentes

Après une mise à niveau de Proxmox, par où commencer ?

Commencez par préserver une sauvegarde vérifiable et relevez la version de l’hôte, son noyau, la configuration de la VM et l’heure du dernier changement. Comparez ces éléments à l’état antérieur, puis reproduisez l’incident sur une copie. Ne modifiez qu’un paramètre à la fois : micrologiciel, ordre de démarrage, contrôleur ou type de processeur.

Que faire si Windows Server 2025 redémarre en boucle sur AMD EPYC ?

Le processeur AMD EPYC ne suffit pas à établir la cause. Notez le code affiché et le stade du redémarrage, vérifiez si l’hôte reste administrable, puis examinez les journaux de Proxmox et l’environnement de récupération Windows. Si le problème suit une mise à jour, testez la configuration précédente sur une copie avant toute modification de la VM de production.

Comment distinguer un réglage de micrologiciel d’un problème de contrôleur ?

Contrôlez d’abord le mode SeaBIOS ou UEFI et l’entrée de démarrage, sans les changer simultanément. Vérifiez ensuite si le disque virtuel est présenté et si le contrôleur correspond au pilote utilisé pendant l’installation de Windows. Voir le disque dans l’environnement de récupération est un indice utile, mais ne prouve ni que le pilote est correct ni que le stockage fonctionne sans défaut.

Comment valider Windows Server 2025 avant de passer à Proxmox VE 9.2 ?

Documentez la configuration actuelle, effectuez une sauvegarde que vous savez restaurer et préparez une copie isolée de la VM. Vérifiez son démarrage avant la mise à niveau, puis après celle-ci, en conservant les mêmes paramètres invités. Planifiez la production seulement après validation des services, de la détection des périphériques et d’un redémarrage contrôlé.

Une fois la VM rétablie, gardez la configuration avant et après l’intervention, les journaux et le résultat de la restauration d’essai dans le dossier d’exploitation : si un symptôme réapparaît, ces éléments permettront de distinguer une nouvelle panne d’un changement déjà testé. Si vos besoins évoluent vers plusieurs VM Windows exploitées en continu, comparez alors les limites de votre solution actuelle aux ressources et options réellement disponibles chez OSFP Cloud.

Questions

Comment enquêter sur une VM Windows Server 2025 qui ne démarre plus après une mise à niveau de Proxmox ?

Commencez par préserver une sauvegarde vérifiable et relevez la version de l’hôte, son noyau, la configuration de la VM et l’heure du dernier changement. Comparez ces éléments à l’état antérieur, puis reproduisez l’incident sur une copie. Ne modifiez qu’un paramètre à la fois : micrologiciel, ordre de démarrage, contrôleur ou type de processeur.

Que vérifier si Windows Server 2025 redémarre en boucle sur un hôte AMD EPYC ?

Le processeur AMD EPYC ne suffit pas à établir la cause. Notez le code affiché et le stade du redémarrage, vérifiez si l’hôte reste administrable, puis examinez les journaux de Proxmox et l’environnement de récupération Windows. Si le problème suit une mise à jour, testez la configuration précédente sur une copie avant toute modification de la VM de production.

Comment différencier un problème de micrologiciel d’un contrôleur de disque incompatible ?

Contrôlez d’abord le mode SeaBIOS ou UEFI et l’entrée de démarrage, sans les changer simultanément. Vérifiez ensuite si le disque virtuel est présenté et si le contrôleur correspond au pilote utilisé pendant l’installation de Windows. Voir le disque dans l’environnement de récupération est un indice utile, mais ne prouve ni que le pilote est correct ni que le stockage fonctionne sans défaut.

Comment tester une VM Windows Server 2025 avant de passer à Proxmox VE 9.2 ?

Documentez la configuration actuelle, effectuez une sauvegarde que vous savez restaurer et préparez une copie isolée de la VM. Vérifiez son démarrage avant la mise à niveau, puis après celle-ci, en conservant les mêmes paramètres invités. Planifiez la production seulement après validation des services, de la détection des périphériques et d’un redémarrage contrôlé.