StackX PX : correctifs de sécurité ciblés pour Proxmox VE 8

StackX PX

Le support officiel de Proxmox VE 8 a pris fin le 31 août 2026. Pourtant, Debian 12 Bookworm, sur laquelle il repose, bénéficie d’un support LTS jusqu’au 30 juin 2028. Ce support Debian ne prend pas en charge les composants propres à Proxmox.

Proxmox propose bien entendu de passer sur VE 9. Et vous savez quoi ? Ça ne me satisfait pas.

Proxmox ne m’appartient pas, ce n’est pas moi qui décide, je n’ai rien à dire. Je l’utilise en production depuis sa version 2.1, peut-être avant, et j’en ai fait la promotion toute une partie de ma vie, et encore aujourd’hui. J’ai littéralement installé des centaines de clusters qui font ou ont fait tourner au total plusieurs dizaines de milliers de VM. Ceci n’est pas un plaidoyer contre Proxmox VE. Longue vie à eux.

Toutefois, je sais exactement ce que j’attends de mon côté d’une solution de virtualisation amenée à faire tourner des systèmes critiques et, en premier lieu, juste après la stabilité, la sécurité et les performances : un support de sécurité au minimum jusqu’au terme LTS de la distribution Linux sur laquelle elle repose.

Je n’ai jamais migré vers une version de Proxmox VE dès sa sortie : aucune version. Chaque migration demande des tests approfondis et des simulations de vraies machines de clients sur les nouvelles infrastructures pour savoir quels peuvent être les impacts sur les VM et la stabilité générale. Je n’ai pas envie de vivre des reboots à répétition, des VM qui se figent ou d’autres problèmes qui ne seront remontés qu’après des semaines, voire des mois d’utilisation.

Ce que je peux tolérer sur une distribution Linux et que je peux plus facilement fixer, je ne peux pas le tolérer sur un hyperviseur. Les migrations précédentes s’accompagnaient le plus souvent d’un changement d’infrastructure. La nouvelle plateforme tournait déjà sur les nouvelles versions, et je migrais de l’une à l’autre.

Cette fois, avec l’explosion du prix des machines, j’ai revu le calendrier : en temps normal, j’aurais renouvelé le matériel début 2027. Là, je vais le garder au moins jusqu’en 2029. Je m’y suis par ailleurs contractuellement engagé.

J’ai donc étudié les impacts de cette migration, la cohabitation temporaire de VE 8 et VE 9 au sein d’un même cluster, et la liste des tests unitaires et fonctionnels à effectuer avant de basculer des centaines de machines clientes.

Dans le lot, certaines machines legacy ont des connexions avec des systèmes industriels ou médicaux. Une modification peut avoir des conséquences importantes et imprévisibles. Il faut vérifier les applications, les échanges avec ces équipements et les comportements dont dépend la production. Ça demande du temps, des essais et du recul.

Comme vous avez pu le voir récemment avec StackX PHP pour Debian 9, 10 et 11, puis avec les noyaux StackX LTS, je ne suis pas du genre à laisser des clients sans solution parce que leur migration prend du temps. Pendant qu’on la prépare et qu’on la valide, leurs services continuent de tourner. J’ai donc entrepris de rétroporter les correctifs de sécurité nécessaires sur les composants concernés de VE 8.

StackX PX publie donc une première série de correctifs de sécurité ciblés pour Proxmox VE 8 sur Debian 12 Bookworm, en amd64. Le dépôt contient cinq paquets applicatifs, une image noyau corrigée et ses en-têtes correspondants.

Pourquoi j’ai décidé de conserver Proxmox VE 8 sur une partie des infrastructures ?

Pour de nouveaux clusters, c’est un arbitrage qui se discute et qui dépend des circonstances : besoins internes, private cloud pour un client, etc. Chaque cas est différent. Mais sur les infrastructures sensibles actuelles, j’ai besoin d’avoir du recul et un environnement parfaitement maîtrisé.

La cohabitation de VE 8.4 et VE 9 dans un même cluster est prévue pendant la mise à niveau, sur une période que Proxmox demande de garder aussi courte que possible. À chaque fois que je me suis retrouvé dans cette situation, c’est ce que j’ai fait. Le plan de retour arrière en cas de soucis n’est pas garanti et peut engendrer des interruptions de service.

VE 9 change la base Debian, le noyau, QEMU, ZFS et plusieurs autres composants. Il est passé à Debian 13 Trixie ; sa première version utilisait Linux 6.14 et QEMU 10, contre Linux 6.8 par défaut et QEMU 9.2 dans VE 8.4. Ces changements peuvent modifier le comportement d’une VM, d’un pilote, d’un stockage ou d’une charge précise.

Rien n’indique, sans effectuer des tests poussés avec des cas réels, que les performances seront au moins identiques aux précédentes : c’est également une raison d’arbitrage, car pour certains de nos clients, quelques ms peuvent faire la différence.

La compatibilité mérite la même précision :

Pour les conteneurs LXC, VE 9 ne permet plus le mode cgroup v1 ou hybride. Les conteneurs avec un systemd antérieur à 232, notamment CentOS 7 ou Ubuntu 16.04, ne disposent donc plus de ce chemin de compatibilité. VE 8 est la dernière branche qui le permet : je ne suis pas concerné, je n’utilise plus de conteneurs depuis bien longtemps, uniquement des VM KVM.

Concernant les VM KVM, le point de vigilance concerne les anciennes versions de machine QEMU. Proxmox indique que les versions antérieures à 6.0 doivent disparaître au cours du cycle VE 9. Leur mise à jour change le matériel virtuel présenté à l’invité et peut demander de réinstaller certains pilotes. La version de machine enregistrée dans un instantané avec mémoire ne peut pas être modifiée ; un tel instantané peut donc devenir impossible à reprendre lorsque cette version disparaît.

Ce n’est pas forcément un cas commun, mais je préfère le prendre en compte.

Enfin, si Proxmox VE 9 ajoute de nouvelles fonctionnalités comme les snapshots sur les stockages LVM thick, des règles d’affinité HA, les fabrics SDN et la possibilité d’ajouter des disques à un pool RAIDZ sans l’arrêter : je ne suis pas concerné.

Je déteste LVM (il en faut pour tous les goûts xD) et je préfère stocker directement sur le système de fichiers sans couche d’abstraction.

Chez ScalarX, les PRD/DRS sont gérés au niveau des VM, comme pour des serveurs dédiés, indépendamment des modes HA des hyperviseurs. Et pour conclure : je n’utilise pas non plus de pool RAIDZ sur les hyperviseurs : ZFS me sert uniquement sur Proxmox Backup Server (PBS) ou éventuellement sur des stockages externes.

Pour être tout à fait honnête, VE 8 offre déjà beaucoup trop de fonctionnalités pour nos propres besoins. C’est d’ailleurs la raison pour laquelle je travaille en parallèle sur mon propre hyperviseur, StackX Hypervisor (SXHV), avec un périmètre plus resserré autour de ce qu’on utilise réellement en production. Il n’est d’ailleurs pas improbable que notre prochaine migration se fasse vers SXHV plutôt que vers VE 9, en tout cas pour les unités Public Cloud de ScalarCloud.

Périmètre de cette première livraison

Les cinq paquets applicatifs conservent le numéro amont de VE 8 et ajoutent une révision +sx. Les sources modifiées sont publiées avec les binaires.

Ce qui a réellement été fait

Les sources de Proxmox VE 8 ont été comparées aux correctifs de sécurité publiés en amont. Les changements nécessaires ont été adaptés aux versions encore utilisées dans VE 8, puis les paquets ont été reconstruits et qualifiés dans leur environnement cible.

Les auteurs des correctifs amont conservent naturellement leur attribution. Le travail StackX porte sur le rétroportage, l’adaptation, la reconstruction, le conditionnement du dépôt et les validations réalisées sur Proxmox VE 8.

Ce qui a été vérifié

Les essais isolés ont couvert les sources, les binaires, leurs dépendances et la sélection des versions exactes par APT. Le lot a ensuite été installé sur nos propres nœuds Proxmox.

Les validations opérationnelles ont notamment porté sur :

• l’installation du lot et le redémarrage sur le noyau StackX ;
• le démarrage et le fonctionnement des VM ;
• les instantanés ;
• la sauvegarde puis la restauration avec Proxmox Backup Server ;
• la migration à chaud.

Ces essais correspondent à nos nœuds, nos configurations et nos usages. Ils ne qualifient pas tous les matériels, pilotes, stockages, réseaux ni scénarios possibles.

Ajouter le dépôt sans rien installer

Avant toute opération, prévoyez une sauvegarde récente et réellement restaurable, un accès à la console de secours, une fenêtre de maintenance et la conservation de l’ancien noyau.

Téléchargez d’abord le script, lisez-le, puis exécutez-le en root :

curl -fsSLo add-stackx-ve8-repo.sh https://mirrors.scalarx.net/stackx-px/ve8/add-stackx-ve8-repo.sh
less add-stackx-ve8-repo.sh
bash add-stackx-ve8-repo.sh

Ce script configure uniquement le dépôt. Il vérifie la plateforme, la clé et l’index signé, puis ajoute la source APT. Il n’installe aucun paquet, ne lance pas apt-get update et ne redémarre rien.

Le dépôt est marqué NotAutomatic: yes. Il ne cherche donc pas à imposer ce lot lors d’une mise à jour ordinaire. Un simple apt upgrade peut ne rien proposer.

Simuler les versions exactes

Actualisez les index, puis simulez explicitement l’installation dans le même shell :

apt-get update

stackx_px_packages=(
  proxmox-ve
  qemu-server=8.4.10+sx00072.5
  libpve-http-server-perl=5.2.2+sx00089.2
  libpve-common-perl=8.3.8+sx00077.2
  pve-manager=8.4.21+sx00077.4
  pve-xtermjs=5.5.0-2+sx00075.2
  proxmox-kernel-6.8.12-43-sx3-pve=6.8.12-43+sx3.1
  proxmox-headers-6.8.12-43-sx3-pve=6.8.12-43+sx3.1
)

apt-get -s --no-install-recommends install "${stackx_px_packages[@]}"

Lisez le résultat obtenu sur votre propre serveur. Il ne doit annoncer aucune suppression ni aucun changement imprévu de paquet ou de dépendance, et doit sélectionner exactement les versions demandées. Le nombre de paquets mis à jour dépend de l’état initial de la machine.

Installer, redémarrer et vérifier

Si et seulement si le plan simulé vous convient, lancez l’installation avec la même variable toujours présente dans le shell :

apt-get --no-remove --no-install-recommends install "${stackx_px_packages[@]}"

L’option --no-remove fait échouer l’opération si APT estime devoir supprimer un paquet. Elle ne remplace pas la lecture préalable de la simulation.

Conservez l’ancien noyau et son entrée de démarrage. Ne lancez pas apt autoremove dans cette procédure. Redémarrez ensuite pendant la fenêtre prévue :

reboot

Après le redémarrage, vérifiez le noyau effectivement chargé :

uname -r

Si le noyau StackX a bien été sélectionné au démarrage, la valeur attendue est 6.8.12-43-sx3-pve. Contrôlez ensuite le réseau, les stockages, les services Proxmox, les VM et les sauvegardes. En cas de problème, l’ancien noyau conservé permet de revenir en arrière depuis le menu de démarrage.

Limites

StackX PX apporte des correctifs ciblés aux paquets listés sur cette page. Il ne constitue pas une maintenance exhaustive de Proxmox VE 8.

Ce premier lot ne remplace pas le binaire pve-qemu-kvm et n’intègre pas de correctif VMA.

Le point VMA a été mis hors du premier lot parce que le scénario décrit dans l’avis Proxmox PSA-2026-00067-1 suppose une archive VMA forgée déposée directement sur le stockage, puis restaurée.

Or, nous utilisons PBS pour les backups. Quand bien même nous déciderions de faire un backup VMA exceptionnel, en local ou via NFS : aucun tiers, client ou prestataire ne dispose du moindre accès permettant de lancer ou de restaurer un backup.

D’autres composants ou avis de sécurité peuvent demander des livraisons séparées.

Le dépôt donne du temps pour qualifier une migration. Il ne transforme pas une branche ancienne en version éternelle et ne dispense jamais d’une sauvegarde restaurable, d’un accès console ni d’un essai sur la plateforme concernée.

Ressources

• Cycle de support officiel de Proxmox VE
• Position de Proxmox sur la cohabitation temporaire de VE 8 et VE 9
• Règles de migration entre VE 8.4 et VE 9 rappelées par l’équipe Proxmox
• Support LTS de Debian 12 Bookworm jusqu’au 30 juin 2028
• Dépôt StackX PX pour Proxmox VE 8
• Script d’ajout du dépôt
• Signature du script
• Clé publique StackX PX
• Index Packages
• Index Sources
• Empreintes des artefacts
• Avis de sécurité Proxmox VE
• Correctif KVM associé à CVE-2026-99082
• Présentation officielle des nouveautés de Proxmox VE 9.0
• Guide officiel de migration de Proxmox VE 8 vers 9
• Politique des versions de machine QEMU dans Proxmox VE

--
Christophe Casalegno
https://all.bo