Veeam signale des pannes de démarrage de sa Software Appliance sur des hôtes AMD EPYC

Veeam a mis en garde ses clients contre des pannes de démarrage qui touchent les machines virtuelles (VM) Software Appliance installées sur des hôtes équipés de processeurs AMD EPYC, rapporte le site américain Bleeping Computer le 6 novembre 2026. Dans un avis publié mercredi, l'éditeur explique que ces VM peuvent s'arrêter par une « kernel panic » (arrêt critique du noyau) au démarrage, après l'échec d'un contrôle effectué en mode FIPS.¹

Les Software Appliance de Veeam sont des machines virtuelles sous Linux, livrées préconfigurées. Elles permettent aux administrateurs de faire tourner la suite de sauvegarde Veeam Backup & Replication sur des systèmes Linux sans installer eux-mêmes les dépendances ni configurer le logiciel. Pour respecter les référentiels de sécurité des entreprises et des administrations, le noyau Linux de ces VM exécute au début du démarrage, en mode FIPS, des contrôles d'intégrité et des contrôles cryptographiques, dont les tests de santé « jitterentropy ».¹

C'est ce test qui pose problème, selon Veeam. « Une machine virtuelle Veeam Software Appliance (Veeam Backup & Replication sous Linux) fonctionnant sur un hôte doté d'un processeur AMD EPYC échoue par intermittence à démarrer après un redémarrage, y compris un redémarrage qui suit une mise à jour installant un nouveau noyau », indique l'éditeur. « Ce problème survient parce que le noyau Linux utilisé par la Veeam Software Appliance exécute un test de santé jitterentropy en mode FIPS au début du démarrage, et ce test échoue par intermittence sur certains processeurs AMD EPYC, notamment les AMD EPYC 7262, 7302 et 7F72. Lorsque le test échoue, le noyau interrompt le démarrage par une kernel panic. »¹

Toujours selon Veeam, ce problème connu vient de la version du noyau Linux qu'utilise l'appliance et concerne la Veeam Software Appliance à partir de la version 13.1. Sur les systèmes touchés, les utilisateurs voient s'afficher le message « Kernel panic - not syncing: jitterentropy: Initialization failed with host not compliant with requirements: 9 ».¹

Des contournements, pas encore de correctif

Pour contourner le problème, Veeam conseille aux administrateurs de redéployer l'appliance sur un hôte Linux doté d'un autre processeur. Si ce n'est pas possible, il leur recommande de désactiver les mises à jour automatiques de l'appliance, de les installer à la main et de surveiller la VM pendant qu'elle redémarre. « Si la kernel panic se produit, éteignez la machine virtuelle puis rallumez-la. Un redémarrage du système d'exploitation invité ne permet pas de récupérer la machine virtuelle », précise l'éditeur. Il ajoute : « Une fois que l'appliance a démarré correctement, aucune autre erreur n'est attendue, et le fonctionnement de Veeam Backup & Replication n'est pas affecté. »¹

Ce que décrit l'avis tel que le rapporte Bleeping Computer, ce sont des moyens de contourner la panne, pas une correction. Aucune date de correctif n'est donnée. Pour les administrateurs dont les hôtes utilisent l'un des processeurs cités, cela signifie qu'ils doivent soit déplacer l'appliance sur un autre matériel, soit renoncer aux mises à jour automatiques et rester présents à chaque redémarrage, puisque l'installation d'un nouveau noyau fait partie des situations qui peuvent déclencher la panne. Selon Veeam, le problème se limite au démarrage et ne touche pas les sauvegardes elles-mêmes. Reste à savoir si un noyau qui règle le comportement du test jitterentropy sera livré, et quand.¹

Le même jour, Veeam a également indiqué que certains de ses produits sont concernés par une vulnérabilité critique du noyau Linux, référencée CVE-2026-98432. Elle se trouve dans le code réseau TCP pour IPv4 et permet à des attaquants distants, sans authentification, d'exécuter des commandes avec les droits root sur les serveurs qui ont des écouteurs Multipath TCP (MPTCP). L'éditeur a corrigé la faille pour une partie des composants touchés et diffuse le noyau corrigé aux systèmes concernés, soit sous forme de correctif privé, soit par le Veeam Updater. L'article ne dit pas si la Software Appliance fait partie de ces composants. Si c'était le cas, les administrateurs des hôtes AMD EPYC concernés devraient installer un noyau corrigé, tout en sachant qu'un redémarrage après mise à jour peut provoquer la panne décrite plus haut.¹

Selon Bleeping Computer, les produits de Veeam ont plus de 550 000 clients, dont 74 % des entreprises du classement Global 2000 et 82 % de celles du Fortune 500. La matière ne précise pas combien de ces clients utilisent la Software Appliance sur les processeurs cités. On ne peut donc pas, à ce stade, mesurer combien d'installations sont réellement touchées.¹

AMD mise sur les centres de données

L'avis de Veeam paraît alors qu'AMD met en avant sa gamme EPYC pour serveurs. Le 19 septembre 2026, le site russe 3DNews rapportait qu'AMD avait publié les premiers résultats détaillés de ses tests des processeurs serveurs Epyc Venice. Au test SPECrate 2026_int_base, le modèle phare Epyc 9996, avec 256 cœurs, aurait été 78 % plus rapide que l'Epyc 9965, doté de 192 cœurs et de l'architecture Zen 5c. Rapporté à un seul cœur, l'avantage de Zen 6c atteindrait environ 34 %. 3DNews précise toutefois que ce n'est pas un gain d'IPC pur, parce que les systèmes comparés ne différaient pas seulement par leur processeur. Il s'agit de résultats publiés par le constructeur lui-même. Les modèles cités par Veeam (EPYC 7262, 7302 et 7F72) ne sont pas ceux de ces tests, et la matière ne dit pas si les nouvelles puces sont concernées par le problème.^1,2

Le même 6 novembre, 3DNews rapportait que Lisa Su, la dirigeante d'AMD, avait confirmé que l'entreprise se présente désormais avant tout comme une société tournée vers les centres de données, comme Nvidia avant elle. À ce stade, rien dans la matière ne relie cette stratégie à l'incident décrit par Veeam. L'éditeur situe l'origine du problème dans la version du noyau Linux de son appliance et ne met pas en cause un défaut des processeurs. La matière ne contient d'ailleurs aucune réaction d'AMD. Les suites dépendront d'un éventuel nouveau noyau livré par Veeam, qui pourrait rendre inutiles les contournements actuels, et d'une éventuelle réaction d'AMD sur le comportement de ces processeurs face au test jitterentropy.^1,4