Incus : le gestionnaire de conteneurs système et de VMs

Incus est le fork communautaire de LXD, créé par Stéphane Graber et maintenu par le projet Linux Containers. Il pilote, dans une seule CLI (incus), à la fois des conteneurs système (des distributions Linux complètes, façon VM légère) et des machines virtuelles QEMU. Open source, simple et robuste, il s'est imposé comme l'alternative légère à Proxmox et le successeur naturel de LXD. Version LTS de référence en 2026 : Incus 7.0. Cette page pose les bases et oriente vers les guides de la section.

Par où commencer avec Incus ?

Le chemin le plus court tient en trois étapes. Installez Incus depuis le dépôt Zabbly ou le paquet natif de votre distribution, en quelques minutes. Suivez ensuite les premiers pas pour lancer votre premier conteneur système et votre première machine virtuelle, puis apprenez à gérer vos instances au quotidien. Si une VM reste bloquée au démarrage, en mode d'urgence, le guide dépanner le boot d'une VM part du symptôme.

Qu'est-ce qu'Incus

Incus est un gestionnaire d'instances : il administre des conteneurs et des VMs via une CLI et une API REST uniques. Là où Docker lance des conteneurs applicatifs (un processus, une image en couches, éphémère), Incus lance des conteneurs système : une distribution complète avec son init (systemd, openrc), des services et des utilisateurs. On s'y connecte comme à une petite machine, et l'instance persiste dans le temps.

Il s'appuie sur des technologies éprouvées du noyau Linux, les namespaces et les cgroups pour les conteneurs, et QEMU/KVM pour les machines virtuelles. Cette double nature en fait un outil polyvalent : un conteneur léger pour un service Linux, une VM complète quand il faut un autre noyau ou une isolation matérielle.

D'où vient Incus : le fork de LXD

Stéphane Graber, ancien responsable de LXD chez Canonical, a lancé Incus en 2023 lorsque LXD a été rapatrié sous la seule gouvernance de Canonical. Incus reprend la même base technique mais sous une gouvernance communautaire (Linux Containers), 100 % open source, sans accord de contribution propriétaire. La société Zabbly, fondée par Graber, en assure l'empaquetage et le support commercial.

Concrètement, pour qui venait de LXD : la CLI passe de lxc à incus, et un outil lxd-to-incus migre une installation existante en place. Deux dynamiques ont accéléré son adoption : le refus du lock-in après le passage de LXD sous CLA Canonical, et l'exode VMware de 2024 qui a poussé à chercher des alternatives ouvertes.

lxd-to-incus a été retiré en juin 2026

L'outil de migration est présent jusqu'à Incus 7.1 et dans les branches LTS (6.0 et 7.0), mais absent à partir de la 7.2. Si vous venez de LXD, installez une LTS sur la cible pour migrer, puis montez de version ensuite. Voir migrer depuis LXD.

Incus face aux autres outils

Chaque outil a sa zone de pertinence. Voici comment situer Incus.

Outil	Nature	Quand le choisir
Incus	conteneurs système + VMs, CLI/API	machines Linux légères et VMs, sans interface lourde
Docker	conteneurs applicatifs	empaqueter et distribuer une application
LXD	équivalent sous Canonical	si vous restez dans l'écosystème Ubuntu/Canonical
Proxmox VE	hyperviseur avec interface web	un serveur de virtualisation complet avec GUI

Glissez pour voir

Incus n'est pas un concurrent de Docker au sens strict : depuis la version 6.3, il sait d'ailleurs lancer des images OCI (Docker), mais son cœur reste le conteneur système et la VM. Face à Proxmox, il offre une approche plus légère et tout en ligne de commande, sans interface web obligatoire (une UI existe néanmoins).

Les fonctionnalités clés

Incus couvre l'ensemble du cycle de vie des instances, ce qui en fait une plateforme complète et pas un simple lanceur de conteneurs.

• Conteneurs et VMs : la même commande gère les deux, avec ou sans l'option --vm.
• Images et remotes : un serveur d'images officiel (images:) fournit des dizaines de distributions prêtes à l'emploi ; on peut aussi créer les siennes.
• Réseau : un bridge NAT par défaut (incusbr0), jusqu'à des réseaux distribués OVN en cluster.
• Stockage : des pools sur dir, btrfs, lvm, zfs ou ceph, avec volumes, snapshots et copies.
• Snapshots et sauvegardes : figer et restaurer une instance, exporter une archive.
• Clustering : regrouper plusieurs nœuds avec base distribuée et placement automatique.
• Devices : attacher disques, cartes réseau, GPU (passthrough), ports (proxy).
• API REST : tout ce que fait la CLI est pilotable à distance et automatisable.

Quelle version installer

Incus suit un modèle LTS annuelle + feature releases mensuelles. Pour la production, ciblez une LTS :

• Incus 7.0 LTS (mai 2026) : la version recommandée pour les nouvelles installations ;
• Incus 6.0 LTS : toujours supportée jusqu'en 2029, utile si votre distribution la fige ;
• feature releases (7.1, 7.2...) : pour tester les nouveautés, supportées seulement jusqu'à la suivante.

Le détail de l'installation (dépôt Zabbly signé ou paquet natif) figure dans le guide d'installation.

Pourquoi je recommande Incus

J'apprécie Incus parce qu'il réconcilie deux mondes : la légèreté des conteneurs et la souplesse des VMs, sans la lourdeur d'un hyperviseur complet. Pour un homelab ou un serveur d'infrastructure Linux, c'est souvent le meilleur compromis : on déploie une machine Debian fonctionnelle en deux secondes, on la sauvegarde par snapshot, on l'automatise par API, et le jour où il faut un noyau différent ou Windows, on bascule sur une VM avec la même commande. La gouvernance communautaire et l'absence de dépendance à un éditeur unique achèvent de me convaincre.

À retenir

• Incus est le fork communautaire de LXD : une seule CLI, incus, pour les conteneurs système et les machines virtuelles QEMU.
• La version de référence est la LTS Incus 7.0 ; les versions intermédiaires ne sont suivies que jusqu'à la suivante.
• Passer d'un conteneur à une VM, pour un autre noyau ou Windows, se fait avec la même commande.
• Le parcours vise un cloud privé souverain, puis la migration d'un parc VMware vers ce socle.
• Les sept temps de la formation suivent l'ordre de la navigation : de l'installation au cloud privé.

FAQ : questions fréquentes sur Incus

Qu'est-ce qu'Incus ?

Quelle différence entre Incus et Docker ?

Quelle différence entre Incus et LXD ?

Incus ou Proxmox VE : lequel choisir ?

Incus est-il gratuit ?

Incus peut-il lancer des conteneurs Docker (OCI) ?

Où mène ce parcours : une alternative souveraine à VMware

Si cette formation va aussi loin, du premier conteneur jusqu'au cloud privé, ce n'est pas par exhaustivité gratuite. L'objectif assumé est d'offrir un chemin de sortie de VMware, entièrement open source et souverain. Depuis le rachat de VMware par Broadcom et la refonte brutale de ses licences, beaucoup d'équipes cherchent à reprendre la main sur leur virtualisation sans dépendre d'un éditeur unique.

Incus, son socle immuable Incus OS, son Operations Center pour piloter la flotte et son Migration Manager pour importer les VM vSphere forment précisément cette réponse. La logique du parcours est donc claire : on reconstruit un cloud privé équivalent à vSphere (machines virtuelles, conteneurs, réseaux distribués, haute disponibilité), puis on y migre l'existant. Les sept étapes ci-dessous suivent cet objectif, de la prise en main jusqu'à la bascule complète du parc.

La formation Incus

Cette section suit une progression en sept temps, du premier conteneur jusqu'au cloud privé. C'est exactement l'ordre de la navigation à gauche : suivez-la dans l'ordre pour apprendre, ou piochez directement la brique dont vous avez besoin.

1. Démarrer avec Incus

Ce premier module pose la distinction fondatrice avec Docker. Incus vs Docker explique que Docker empaquette une application éphémère, alors qu'Incus fournit une machine Linux complète qui persiste dans le temps. Installer Incus prend ensuite quelques minutes sur Debian, Ubuntu ou une distribution RPM, via le dépôt Zabbly signé ou le paquet natif. Une fois incus admin init passé, les premiers pas lancent votre premier conteneur système ou votre première machine virtuelle avec une seule commande, puis exec et snapshot. C'est le socle à maîtriser avant d'aborder le réseau, le stockage ou le cluster.

2. Exploiter Incus au quotidien

C'est le cœur du métier d'un administrateur Incus. Gérer ses instances couvre le cycle de vie (démarrer, cloner, snapshot, exporter), puis les conteneurs OCI permettent de lancer une image Docker Hub dans Incus. Le réseau connecte les conteneurs via le bridge incusbr0 (NAT, device proxy, DNS), le stockage provisionne des pools ZFS ou LVM avec volumes et snapshots, et les profils et projets industrialisent et cloisonnent la configuration.

S'ajoutent les besoins concrets du terrain : le passthrough GPU pour attacher une carte NVIDIA à un conteneur ou une VM, l'accès distant et l'interface web pour piloter des serveurs à distance, et l'automatisation des images avec Packer et Ansible. Le module se termine par la sécurisation des instances non privilégiées, avec limites et projets restreints, puis par le dépannage d'une VM au boot pour récupérer une machine bloquée en mode d'urgence.

3. Incus OS, le socle immuable

Incus OS, c'est quoi ? Un système d'exploitation immuable dédié à Incus : aucun paquet à gérer, aucun shell, tout passe par une API authentifiée. Les partitions système sont en lecture seule, et c'est le socle qu'on choisit quand la reproductibilité et une surface d'attaque réduite priment sur la souplesse d'un serveur classique. Incus OS sans interface présente cet hôte qu'on ne bricole plus à la main et son installation par seed. Les mises à jour A/B et le rollback s'appliquent de façon atomique, avec retour arrière automatique en cas d'échec. Tailscale sur les nœuds relie ensuite les machines par un réseau maillé privé, et la sauvegarde et supervision protègent et surveillent un socle sans shell.

4. Cluster et haute disponibilité

Un cluster Incus regroupe plusieurs serveurs sous une base de données distribuée, avec placement automatique des instances et haute disponibilité. Le cluster haute disponibilité montre que trois nœuds suffisent à obtenir un quorum qui survit à la panne d'une machine, avec le placement et evacuate. Cluster Incus OS : rôles et HA explique comment répartir les rôles (base de données, OVN, workers) et tenir le quorum, puis workers et nœuds distants étend le cluster à des machines éloignées. Le module se termine par le stockage partagé CephFS : sans lui, une instance reste clouée à son nœud ; avec lui, elle migre à chaud d'un serveur à l'autre. C'est le prérequis de tout cloud privé sérieux.

5. Cloud privé (IaaS)

C'est le sommet du parcours : transformer le cluster en cloud privé, un IaaS souverain comparable à un AWS en réduction. On y bâtit d'abord des réseaux virtuels OVN avec leurs load balancers (réseau OVN), l'équivalent des VPC distribués. Les network ACL segmentent ensuite le trafic comme des Security Groups. Le cloud privé multi-tenant isole plusieurs tenants dotés de leurs projects, quotas, credentials scopés et peering entre VPC. Operations Center pilote la flotte de clusters, et Terraform pour une 3-tiers décrit l'ensemble en Infrastructure as Code. Au bout de la chaîne : une plateforme multi-tenant montée sur ses propres machines, sans dépendre d'un fournisseur externe.

6. Migrer vers Incus

Adopter Incus, c'est rarement partir d'une page blanche. Ce module couvre les trois chemins de migration vers Incus. Depuis VMware, Migration Manager orchestre le transfert des machines virtuelles, un sujet brûlant depuis l'exode qui a suivi le rachat de VMware. Depuis LXD, la migration depuis LXD bascule une installation existante en place avec lxd-to-incus, sans tout réinstaller. Et pour n'importe quel serveur physique ou virtuel, incus-migrate importe la machine dans un conteneur ou une VM Incus. De quoi rapatrier un parc entier de façon progressive.

7. Infrastructure as Code

Une infrastructure Incus décrite en code devient reproductible, versionnée et relue comme n'importe quel logiciel. Ce module présente deux approches complémentaires. Le provider Terraform lxc/incus provisionne réseaux, profils et instances de façon déclarative, et se prête aux montages complexes comme une architecture 3-tiers complète. Le connection plugin Ansible pousse ensuite la configuration à l'intérieur des instances, sans même passer par SSH. Ensemble, ils ferment la boucle : on ne clique plus, on applique un plan, et l'infrastructure se reconstruit à l'identique à la demande.

Plus d'infos

• Site officiel d'Incus
• Documentation officielle
• Dépôt GitHub lxc/incus
• Serveur d'images Incus

×

📖 Voir la documentation →