Multipass 1.17 sort du tout-Ubuntu et ajoute Debian, Fedora et des zones de disponibilité
Sorti le 19 octobre 2026, Multipass 1.17 ajoute Debian et Fedora à un catalogue jusque-là réservé à Ubuntu et introduit des zones de disponibilité pour simuler un cloud en local. Migrez vos instances VirtualBox et LXD sans attendre : les pilotes qui les portaient disparaissent dans cette version.
19 octobre 2026. Canonical publie Multipass 1.17, la première version de son lanceur de machines virtuelles à accepter autre chose que des images Ubuntu. 2017. L’outil est né avec une promesse unique : créer une VM Ubuntu en une seule commande, sur Windows, macOS ou Linux. 1.17. La sortie ajoute Debian et Fedora, des zones de disponibilité, et deux nouveaux pilotes de virtualisation, tout en supprimant les anciens. Le point qui compte : Canonical abandonne le confort du tout-Ubuntu au moment exact où les développeurs ont besoin de tester un logiciel sur plusieurs distributions sans changer d’outil.
Un lanceur né tout-Ubuntu
Multipass occupe une case singulière dans l’écosystème Canonical. Ce n’est pas un hyperviseur complet, ni une simple CLI : c’est la façon la plus rapide de poser une VM Ubuntu sur un poste de travail, avec une seule commande, puis d’y entrer. L’outil gère lui-même le téléchargement des images cloud, la création de l’instance, la configuration réseau et le partage de dossiers entre l’hôte et l’invité.
Cette simplicité avait un prix : Multipass ne lançait que des images Ubuntu. Pour un développeur qui maintient un service censé tourner aussi sur Debian ou Fedora, l’outil était au mieux un point de départ, au pire un angle mort — il fallait ressortir QEMU, Vagrant ou un autre hyperviseur pour tester l’autre moitié du monde. La version 1.16 avait déjà ouvert une brèche en autorisant les images personnalisées ; la 1.17 transforme la brèche en porte.
Derrière cette trajectoire, il y a une réalité de marché : le poste de développement est devenu le premier terrain d’entraînement du cloud. Un développeur qui teste son application sur une VM locale est, quelques semaines plus tard, celui qui la déploie sur une instance AWS, Azure ou Google Cloud. Canonical l’a compris : garder Multipass verrouillé sur Ubuntu, c’était abandonner ce chemin d’adoption à des outils qui, eux, ne font aucune préférence de distribution.
Debian et Fedora entrent au catalogue
Le changement le plus visible est l’arrivée de Debian et Fedora comme images officielles, aux côtés d’Ubuntu. Il ne s’agit pas d’une astuce de téléversement manuel : ces deux distributions sont désormais des citoyennes de première classe du catalogue, sélectionnables dans l’interface comme en ligne de commande.
multipass launch debian
multipass launch fedora --name fedora-41
multipass findConcrètement, un développeur peut désormais lancer trois machines — une Ubuntu, une Debian, une Fedora — avec le même outil, le même flux de travail et le même partage de dossiers, puis valider qu’un script d’installation se comporte à l’identique sur les trois. Canonical dit explicitement vouloir « ouvrir la porte » à d’autres distributions selon les retours : la liste n’est pas figée, et c’est la vraie nouveauté stratégique. Une entreprise qui pousse au tout-Ubuntu a plus à perdre qu’à gagner à aider ses utilisateurs à tester Debian — sauf si elle a compris que le poste de développement est la porte d’entrée du cloud, et qu’un outil verrouillé finit simplement remplacé.
Des zones de disponibilité pour simuler le cloud
La seconde nouveauté structurante est l’introduction des zones de disponibilité (availability zones). L’idée : organiser les VM locales en zones nommées, chacune avec son propre sous-réseau isolé, pour reproduire en local la topologie d’un cloud avant de la déployer.
multipass launch --zone eu-central-1
multipass zones
multipass disable-zones eu-central-1Quand une zone est désactivée, toutes les instances qu’elle contient sont marquées indisponibles — exactement le comportement d’une zone en panne chez un fournisseur cloud. C’est un outil d’entraînement précieux : on peut simuler la perte d’une zone, vérifier qu’une application bascule correctement, puis tout réactiver, sans toucher à une infrastructure réelle. Les zones sont prises en charge sur QEMU (Linux et macOS), sur le nouveau framework Apple Virtualization et sur le pilote HCS de Windows. À la mise à niveau, les instances existantes sont placées d’office dans la zone 1.
Deux nouveaux pilotes, trois architectures de plus
Sous le capot, Multipass 1.17 change aussi de fondations. Sur Windows, un nouveau pilote fondé sur les API Host Compute System (HCS) remplace l’intégration Hyper-V historique et, surtout, fonctionne sur toutes les éditions, y compris Windows Home. Les pilotes Hyper-V et VirtualBox sont dépréciés ; un chemin de migration est prévu pour les VM Hyper-V existantes, mais pas pour celles de VirtualBox.
Sur macOS, un pilote basé sur le framework de virtualisation d’Apple arrive en avant-première, avec un démarrage plus rapide et le support natif des images disque ASIF sur macOS 26. Il est appelé à devenir le pilote par défaut. Enfin, l’outil tourne désormais aussi sur IBM POWER (ppc64el) et IBM Z (s390x), avec des snaps officiels pour les deux architectures.
Le choix du framework Apple Virtualization n’est pas cosmétique. QEMU et VirtualBox restent pris en charge sur Intel/x86, mais le pilote natif démarre plus vite et gère nativement les images ASIF — un détail qui compte sur les Mac récents, où l’émulation devient le goulot d’étranglement. Canonical prévoit d’en faire le pilote par défaut puis de déprécier les autres, exactement comme il vient de le faire sur Windows avec HCS.
Ce qui disparaît — et ce qu’il faut migrer
Toute version « large » a une contrepartie : Multipass 1.17 achève le cycle de dépréciation annoncé en 1.16 en supprimant les pilotes LXD et libvirt, ainsi que les blueprints et les appliances. Pour les équipes qui avaient bâti des scripts sur ces pilotes, la migration n’est pas optionnelle.
Quelques changements cassants méritent attention. Les codes de sortie sont unifiés : multipass shell et multipass exec propagent désormais le code de sortie de la commande exécutée dans l’instance, le code 255 étant réservé aux erreurs propres à Multipass. Les chemins de montage sont normalisés (les barres obliques finales sont supprimées), et l’ordre des clés en sortie --format json n’est plus garanti. Pour les environnements scriptés, la commande multipass wait-ready bloque jusqu’à ce que le démon soit prêt — un ajout pensé pour l’automatisation, pas pour l’interactif.
Où Multipass se place face à la concurrence
Multipass n’est pas seul sur ce créneau. Vagrant, chez HashiCorp, provisionne des VM multi-distributions depuis des années, mais impose des fichiers de configuration en Ruby que beaucoup jugent disproportionnés pour une simple VM de test. Lima automatise des VM Linux sur macOS, via QEMU ou le framework Apple Virtualization ; Podman Machine fait la même chose pour qui préfère travailler en conteneurs. Face à eux, Multipass conserve un avantage simple : lancer une image ne demande aucune configuration, et monter un dossier de l’hôte se fait en une commande.
Cette version clarifie le positionnement. En ajoutant Debian et Fedora, Canonical retire l’argument principal qui poussait les développeurs vers Vagrant — la couverture multi-distributions — tout en gardant sa simplicité de commande unique. Les zones de disponibilité, elles, n’ont pas d’équivalent direct chez Lima ni Podman Machine : elles s’adressent au développeur qui écrit pour le cloud et veut répéter localement ce qu’il déploiera demain. Multipass n’est plus un simple lanceur de VM, c’est un établi de simulation de cloud.
Verdict
Si vous testez un logiciel sur plusieurs distributions, Multipass 1.17 est désormais l’outil le plus court pour le faire : une seule commande par distribution, un même partage de dossiers, et des zones de disponibilité pour répéter vos scénarios de bascule en local. Si vos scripts s’appuient encore sur les pilotes LXD, libvirt ou VirtualBox, planifiez la migration maintenant — la suppression est déjà actée, et le chemin automatique n’existe pas pour VirtualBox. La leçon dépasse l’outil : un éditeur qui verrouille son écosystème finit par être contourné, et Canonical vient de choisir, pour une fois, d’ouvrir avant d’être forcé.