Felipe Borges a annoncé le 3 août une bêta de GNOME Boxes réécrit, après deux ans passés à reconstruire de zéro l'outil de virtualisation du bureau. Le portage vers GTK4 et libadwaita en est la moitié visible. La moitié lourde de conséquences, c'est que le nouveau Boxes ne sort qu'en Flatpak, en embarquant toute la pile de virtualisation au lieu de dépendre des versions de libvirt, QEMU et SPICE que votre distribution transporte. Concrètement, il installe désormais Windows 11 sans contournement manuel pour le démarrage sécurisé ni le TPM, ajoute un périphérique VSOCK pour atteindre les invités, et gagne la redirection de ports. Cible : GNOME 51, en septembre.
The short answer
Felipe Borges a publié le 3 août 2026 une bêta de GNOME Boxes réécrit, disponible sous le nom org.gnome.Boxes.Devel dans le dépôt Flatpak GNOME Nightly. L'application passe à GTK4 et libadwaita, et l'ancien widget d'affichage SPICE en GTK3 cède la place à libmks. La distribution devient exclusivement Flatpak, avec toute la pile de virtualisation embarquée plutôt que les versions fournies par votre distribution. Côté fonctions, Boxes installe désormais Windows 11 sans contournement manuel du démarrage sécurisé ni du TPM, ajoute un périphérique VSOCK pour l'accès SSH aux invités sous systemd 256 ou plus récent, et prend en charge la redirection de ports vers les services invités. Borges parle d'une bêta de test, pas de production, et conseille de sauvegarder.
GNOME Boxes occupe une position inconfortable depuis des années : assez accueillant pour qu'on le recommande aux débutants, assez limité pour que la plupart de ces débutants finissent quand même dans virt-manager à éditer du XML libvirt. La bêta publiée par Felipe Borges le 3 août tente de combler cet écart, et la partie intéressante n'est pas la nouvelle bibliothèque graphique.
La réécriture, et ce qu'elle remplace
Deux ans de travail, décrits par Borges comme une reconstruction de l'application depuis la base plutôt qu'un portage.
Le changement de bibliothèque va de GTK3 à GTK4 avec libadwaita, ce qui aligne l'interface sur le reste des applications GNOME modernes et, comme le dit Borges, rend le code nettement plus facile à maintenir. C'est cette seconde moitié qui compte pour la survie du projet, car une application à laquelle personne ne peut contribuer a une durée de vie limitée, quelle que soit son allure.
Le remplacement précis qui mérite d'être nommé concerne le widget d'affichage. Boxes utilisait un widget d'affichage SPICE en GTK3, c'est-à-dire le composant qui dessine réellement l'écran de l'invité dans la fenêtre. La réécriture le remplace par libmks. C'est le type de changement qu'on ne voit jamais directement et qu'on ressent en permanence, puisque le widget d'affichage est l'endroit où vivent la latence des entrées, le comportement de mise à l'échelle et la gestion du redimensionnement.
Le Flatpak exclusif est la vraie décision
Tout ce qui précède est de la modernisation. Le changement de mode de distribution est un choix à conséquences.
Le nouveau Boxes sort en Flatpak, et uniquement en Flatpak. Borges le présente comme la suppression du coût de maintenance lié à la prise en charge de plusieurs distributions, et comme l'embarquement de la pile de virtualisation complète afin de disposer du contrôle nécessaire pour affiner le fonctionnement.
Mesurez ce que cela signifie pour une interface à libvirt et QEMU. Jusqu'ici, Boxes était une couche mince posée sur les versions de libvirt, QEMU et SPICE fournies par votre distribution. La même version de Boxes se comportait différemment d'une distribution à l'autre, et un rapport de bogue n'avait presque aucun sens sans la liste complète des versions de la pile. L'embarquement fait disparaître cela : un seul QEMU, un seul libvirt, un seul jeu d'options, partout identiques.
Le coût est tout aussi réel. Vous renoncez à l'intégration de votre distribution et à son rythme de mises à jour pour ces composants. Si vous faites déjà tourner libvirt sur la machine et attendez de Boxes qu'il soit un client parmi d'autres, partageant ses définitions avec virt-manager, cette attente ne tient plus vraiment. Le compromis est bon ou mauvais selon que vous traitez Boxes comme un appareil autonome ou comme un visage graphique sur une infrastructure que vous administrez aussi autrement.
Windows 11 sans le rituel
C'est le changement le plus susceptible de faire basculer quelqu'un.
Windows 11 exige le démarrage sécurisé et un périphérique TPM 2.0. Dans une machine virtuelle, c'est à l'hyperviseur de fournir les deux, ce qui imposait jusqu'ici de sélectionner une image de micrologiciel OVMF avec démarrage sécurisé activé et d'attacher un TPM émulé par swtpm. Aucune de ces étapes n'est conceptuellement difficile. Les deux sont fastidieuses, peu documentées et faciles à rater subtilement, l'erreur n'apparaissant qu'au moment où l'installateur Windows refuse de continuer. Beaucoup de gens sont arrivés jusqu'à ce message avant d'aller chercher virt-manager.
Le Boxes réécrit configure les deux automatiquement. Une image ISO de Windows 11 s'installe désormais comme n'importe quel autre invité.
Entrer dans l'invité
Deux ajouts couvrent les deux besoins réels d'une machine virtuelle de bureau.
Un périphérique VSOCK fournit un accès SSH aux invités exécutant systemd version 256 ou plus récente, version à partir de laquelle la prise en charge côté invité est arrivée. VSOCK est une famille de sockets conçue pour la communication entre hôte et invité qui contourne entièrement la pile réseau, et fonctionne donc que l'invité dispose ou non d'une adresse IP joignable depuis l'hôte. Cela supprime une catégorie de frustration bien connue, celle de la machine virtuelle qui tourne parfaitement et reste simplement inaccessible.
La redirection de ports couvre l'autre moitié : associez un port de l'hôte à un port de l'invité et un service exécuté dans la machine virtuelle devient joignable depuis l'hôte. Entre les deux, un shell et un service, sans configurer le réseau invité à la main.
Ce que nous ferions
Installez-la à côté de la version stable, pas par-dessus.
La bêta est publiée sous le nom org.gnome.Boxes.Devel dans le dépôt Flatpak GNOME Nightly, ce qui signifie qu'elle cohabite avec un Boxes stable au lieu de le remplacer. Borges dit clairement qu'il s'agit d'une bêta de test et non de production, et recommande de sauvegarder les données des machines virtuelles avant d'essayer. Pour un outil dont le mode de défaillance est une image disque, ce conseil mérite d'être suivi à la lettre.
La réécriture finie vise GNOME 51, le 16 septembre. Six semaines, c'est court pour une application reconstruite de zéro, surtout maintenue en parallèle de GNOME Settings et d'autres responsabilités chez Red Hat, en grande partie sur le temps libre de son auteur. Si vous avez un cas d'usage que l'ancien Boxes traitait mal, c'est le bon moment pour le tester et déposer quelque chose de précis, car c'est là qu'un rapport de bogue vaut le plus cher.
Sources et pour aller plus loin
- Felipe Borges, The Future of GNOME Boxes, 3 août 2026
- GNOME Boxes preparing to deliver much improved virtualization experience, Phoronix, 3 août 2026
- Discussion de l'annonce sur GNOME Discourse
- Compilations nocturnes de GNOME Boxes
Questions fréquentes
Pourquoi le choix du Flatpak seul compte-t-il autant pour un outil de virtualisation ?
Parce que Boxes est une interface pour libvirt et QEMU, et qu'une interface n'est jamais plus prévisible que la pile qu'elle recouvre. Historiquement, Boxes tournait sur les versions de libvirt, QEMU et des bibliothèques SPICE fournies par votre distribution, si bien que la même version de Boxes se comportait différemment sur Fedora, Debian et Arch, et qu'un rapport de bogue était rarement reproductible sans connaître toute la pile. Borges décrit le choix du Flatpak comme l'embarquement de la pile de virtualisation complète, ce qui supprime cette variable : tout le monde exécute le même QEMU, avec les mêmes options, sur le même libvirt. Le coût est réel lui aussi. Vous renoncez à l'intégration de votre distribution, à son rythme de mises à jour de sécurité pour ces composants, et à la possibilité de partager une configuration libvirt avec virt-manager comme vous pourriez l'attendre. La question est de savoir si vous utilisez Boxes comme un appareil autonome ou comme un client parmi d'autres.
Qu'est-ce qui change pour installer Windows 11 ?
Windows 11 exige le démarrage sécurisé et un périphérique TPM 2.0, et dans une machine virtuelle les deux doivent être fournis par l'hyperviseur. Avec l'ancien Boxes, cela signifiait configurer un micrologiciel OVMF avec démarrage sécurisé activé et rattacher un TPM émulé par swtpm, généralement en éditant le XML libvirt à la main ou en renonçant pour passer à virt-manager. Le Boxes réécrit configure les deux automatiquement, si bien qu'une image ISO de Windows 11 s'installe comme n'importe quel autre invité. C'est le changement le plus susceptible de convaincre quelqu'un de basculer, car le chemin manuel est moins difficile que fastidieux, mal documenté et facile à rater subtilement, l'erreur n'apparaissant qu'au contrôle de compatibilité de l'installateur Windows.
À quoi servent VSOCK et la redirection de ports ici ?
Ce sont deux réponses au même problème : atteindre quelque chose à l'intérieur de la machine virtuelle depuis l'hôte. VSOCK est une famille de sockets conçue pour la communication entre hôte et invité sans passer du tout par la pile réseau, donc elle fonctionne même si l'invité n'a pas d'adresse IP routable depuis l'hôte. Boxes s'en sert pour proposer un accès SSH aux invités exécutant systemd version 256 ou plus récente, version à partir de laquelle la prise en charge côté systemd est arrivée. La redirection de ports est la réponse plus classique : vous associez un port de l'hôte à un port de l'invité pour qu'un serveur web ou une base de données à l'intérieur de la machine virtuelle soit joignable depuis l'hôte. À elles deux, elles couvrent les deux besoins les plus fréquents d'une machine virtuelle de bureau, un shell et un service, sans configurer le réseau invité à la main.
Faut-il installer la bêta ?
Uniquement sur une machine où perdre une machine virtuelle serait un désagrément et non un problème. Borges précise explicitement qu'il s'agit d'une bêta destinée aux tests et pas aux environnements de production, et il conseille de sauvegarder les données des machines virtuelles avant d'essayer. Cet avertissement mérite d'être pris au pied de la lettre pour un outil dont le mode de défaillance est une image disque. Installez-la sous le nom org.gnome.Boxes.Devel depuis le dépôt Flatpak GNOME Nightly, qui cohabite avec un Boxes stable au lieu de le remplacer : vous pouvez donc essayer le nouveau sur un invité jetable en gardant l'ancien pour ce qui compte. Si vous voulez aider, la contribution utile est un rapport de bogue issu d'un usage réel plutôt qu'une première impression.
Quand arrive la version finie ?
La réécriture vise GNOME 51, prévu pour le 16 septembre 2026. Cela laisse environ six semaines depuis la bêta, une piste courte pour une application reconstruite de zéro, et nous ne serions pas surpris de voir certaines parties arriver plus tard ou avec des aspérités. Il faut aussi savoir avec quels moyens ce travail est mené : Borges maintient Boxes en parallèle de GNOME Settings et de ses autres responsabilités chez Red Hat, et décrit une bonne partie du travail sur Boxes comme réalisée sur son temps libre. Une réécriture complète menée sur deux ans dans ces conditions est une performance, et c'est aussi une raison de calibrer ses attentes sur la vitesse à laquelle les manques restants seront comblés.