Canonical a confirmé une pile d'activation matérielle pour la virtualisation sur Ubuntu 26.04 LTS, ce qui permet à un hôte LTS de suivre des versions plus récentes de QEMU, libvirt, EDK2 et SeaBIOS sans basculer sur une version intermédiaire. Les paquets portent un suffixe hwe, ils se rafraîchissent tous les six mois pendant les deux premières années de la version, et rien ne change tant que vous ne le demandez pas. L'intéressant n'est pas la montée de version. C'est que Canonical traite l'hyperviseur, la couche de gestion et le micrologiciel invité comme un ensemble qu'on déplace en bloc, avec un outil qui empêche de n'en déplacer qu'une partie.
The short answer
Canonical livre une pile d'activation matérielle pour la virtualisation sur Ubuntu 26.04 LTS, composée de qemu-hwe pour l'hyperviseur, libvirt-hwe pour la gestion, edk2-hwe pour le micrologiciel UEFI des invités dont OVMF, et seabios-hwe pour les invités en BIOS classique. Les paquets se rafraîchissent tous les six mois pendant les deux premières années de la version, et un outil nommé ubuntu_virt_helper les gère comme un ensemble unique, ce qui rend les montées partielles impossibles. C'est optionnel : les systèmes de base gardent les paquets de base. Canonical vise les VM confidentielles sur AMD SEV-SNP ou Intel TDX, les charges réglementées et le cloud souverain.
Quiconque a fait tourner des machines virtuelles sur une LTS pendant quelques années connaît la forme de ce problème. Vous achetez du matériel neuf, ce matériel a une fonction que vous voulez, et le QEMU de votre distribution est antérieur de dix huit mois à cette fonction.
Le décalage que cela comble
Le noyau HWE existe depuis des années et règle la moitié évidente du problème. Du silicium neuf demande un noyau neuf, les LTS livrent des noyaux anciens, donc Canonical en rétroporte de plus récents et une installation LTS reconnaît des machines qui n'existaient pas à la sortie de la version.
La virtualisation connaît le même décalage et le noyau seul n'y suffit pas. Exposer une capacité de processeur à un invité est une chaîne : le noyau hôte doit la gérer, QEMU doit la modéliser et l'exposer comme fonction de CPU ou comme périphérique, libvirt doit savoir la décrire dans le XML de domaine, et pour tout ce qui touche au démarrage le micrologiciel invité doit la négocier. Cassez un maillon et la fonction n'est pas là, quelle que soit la fraîcheur de votre noyau.
Cette chaîne explique pourquoi l'annonce porte sur quatre paquets et pas un. qemu-hwe porte l'hyperviseur et l'émulation système, libvirt-hwe la couche de gestion, edk2-hwe le micrologiciel UEFI dont OVMF, et seabios-hwe le micrologiciel BIOS classique pour les invités plus anciens.
Les déplacer en bloc
La décision de conception à retenir est l'outil d'accompagnement. ubuntu_virt_helper existe pour gérer la pile comme une unité complète, et son rôle est d'empêcher les états mixtes vers lesquels les administrateurs glissent quand ils ne veulent qu'une seule chose plus récente.
Quiconque a tenté de tirer un seul QEMU récent sur un hôte par ailleurs intact sait pourquoi cela compte. Un QEMU récent face à un vieux libvirt donne une couche de gestion incapable de décrire ce que l'hyperviseur sait maintenant faire. Un QEMU récent face à un vieil OVMF donne des invités qui démarrent jusqu'au jour où l'un d'eux a besoin d'un comportement de micrologiciel absent. Les définitions de types de machine se résolvent différemment d'une version à l'autre, et c'est la classe de bug où la migration à chaud fonctionne dans un sens et pas dans l'autre, sans que rien dans les journaux ne l'explique pendant la première heure.
Regrouper les quatre et les déplacer ensemble n'élimine pas cette surface, mais garantit que la combinaison présente sur votre hôte est une combinaison testée par Canonical, et non une combinaison inventée à deux heures du matin.
La cadence et la fenêtre
Les paquets hwe se rafraîchissent tous les six mois, en suivant les versions amont plus récentes disponibles dans Ubuntu, et cela court sur les deux premières années du cycle de vie de 26.04.
Deux ans de pas de six mois représentent environ quatre sauts de version, ce qui place un hôte 26.04 dans un état sensiblement différent en fin de fenêtre de ce que donneraient les paquets de base. Une fois la fenêtre fermée, la pile cesse d'avancer, exactement comme le modèle du noyau HWE se comporte depuis toujours. L'échange est énoncé clairement plutôt que dissimulé : vous acceptez plus de changement en échange du suivi du matériel, selon un calendrier lisible à l'avance.
Le caractère optionnel fait aussi un vrai travail. Un système 26.04 existant garde les paquets de virtualisation de base tant que personne n'installe délibérément les variantes hwe. Il n'y a pas de bascule automatique ni de valeur par défaut qui change sous un parc en production, ce qui, pour une classe d'hôtes où un redémarrage surprise déplace beaucoup d'invités, est le seul choix défendable.
Qui doit s'en soucier
La liste de cas visés par Canonical est étroite et honnête : les VM confidentielles utilisant AMD SEV-SNP ou Intel TDX, les charges réglementées qui exigent une isolation plus forte entre locataires, l'inférence confidentielle pour les travaux d'IA, les plateformes de cloud privé ou souverain, et les infrastructures qui doivent tenir des années sans prendre du retard sur le matériel qu'elles portent.
Leur point commun est une dépendance à des capacités de processeur récentes. Si vos hyperviseurs tournent sur du matériel que le QEMU de base de 26.04 gère déjà complètement, et si vos invités sont des charges Linux et Windows ordinaires, la pile de base reste la bonne réponse et le restera pour la durée de vie de la version. Ajouter quatre paquets sur un tapis roulant de six mois pour ne rien gagner n'est pas une amélioration.
Si vous montez une plateforme sur du silicium de génération actuelle et qu'il vous manque une capacité arrivée en amont après le gel de 26.04, c'est le mécanisme qui n'existait pas jusqu'ici. Les options précédentes consistaient à faire tourner une version intermédiaire sur des hyperviseurs de production, ce dont personne ne veut, ou à compiler QEMU soi même et à en porter la charge pour toujours, ce qui est pire. Une voie médiane prise en charge est réellement nouvelle.
Sources et pour aller plus loin
- Canonical : la pile HWE de virtualisation Ubuntu
- Documentation serveur Ubuntu : pile d'activation matérielle pour la virtualisation
- Phoronix : Ubuntu va fournir une pile HWE de virtualisation pour Ubuntu 26.04 LTS
- 9to5Linux : Canonical introduit la pile HWE de virtualisation pour Ubuntu 26.04 LTS
- Linuxiac : Ubuntu 26.04 LTS reçoit une pile HWE de virtualisation optionnelle
Questions fréquentes
Ai je quelque chose à faire si je fais tourner des VM Ubuntu aujourd'hui ?
Non. La pile est optionnelle par conception, et Canonical est explicite : un système existant conserve les paquets de virtualisation de base tant qu'un administrateur n'installe pas délibérément les variantes hwe. Il n'y a pas de migration automatique, pas de date butoir, et aucun changement sur les paquets déjà présents sur un hôte 26.04. Si vos hyperviseurs fonctionnent et si le matériel qui les porte est entièrement pris en charge par la version de QEMU de la base, l'action correcte consiste à lire ceci, le noter, et continuer.
En quoi est ce différent du noyau HWE ?
C'est la même idée appliquée un étage au dessus. Le noyau HWE existe parce que le matériel sort plus vite que les versions LTS, donc Canonical rétroporte un noyau plus récent pour qu'une installation LTS reconnaisse des machines plus récentes. La virtualisation connaît le même décalage pour une autre raison : la prise en charge d'une fonction de processeur dans un invité demande le noyau, mais aussi QEMU pour l'exposer, libvirt pour la décrire, et souvent le micrologiciel invité pour la négocier. Obtenir un noyau plus récent seul ne suffit pas. La pile HWE de virtualisation couvre la moitié espace utilisateur et micrologiciel de cette chaîne.
Qu'est ce que ubuntu_virt_helper empêche exactement ?
Le mode de défaillance où l'on met à jour un composant en laissant les autres en arrière. QEMU, libvirt et le micrologiciel invité sont trois pièces qui doivent s'accorder, et un hôte qui fait tourner un QEMU récent avec un vieil OVMF, ou un libvirt récent face à un vieux QEMU, produit le genre de problème qui mange un jeudi : un invité qui démarre mais ne voit pas une fonction, un type de machine qui se résout autrement que ce que le XML attendait, une migration qui échoue dans un seul sens. L'outil traite les quatre paquets comme un ensemble, donc les combinaisons obtenues sont des combinaisons que Canonical a réellement testées.
Quelle est la cadence de mise à jour et que se passe t il après deux ans ?
Les paquets hwe se rafraîchissent tous les six mois, en suivant les versions amont plus récentes disponibles dans Ubuntu, et cette cadence court sur les deux premières années du cycle de vie de 26.04 LTS. Passée cette fenêtre, la pile cesse d'avancer, ce qui reprend le fonctionnement du modèle du noyau HWE depuis toujours. Deux ans de pas de six mois font environ quatre sauts de version, une position très différente de celle où se trouve normalement un hôte LTS en fin de vie. Planifiez comme vous planifiez l'adoption d'un noyau HWE : prenez la pile récente là où vous avez besoin du support matériel, restez sur les paquets de base ailleurs.
Pour qui est ce vraiment fait ?
Canonical nomme les cas directement, et ils tournent autour des fonctions d'isolation matérielle. Les VM confidentielles utilisant AMD SEV-SNP ou Intel TDX, les charges réglementées qui exigent une séparation plus forte entre locataires, l'inférence confidentielle pour les travaux d'IA, et les plateformes de cloud privé ou souverain. Leur point commun est une dépendance à des capacités de processeur très récentes, exactement la situation où un hôte LTS avec un QEMU de dix huit mois ne peut pas exposer ce dont le silicium en dessous est capable. Si rien de tout cela ne décrit votre parc, la pile de base reste le bon défaut et le restera probablement pour la durée de vie de la version.