La migration à chaud de conteneurs a toujours eu une réponse embarrassante dans le monde Linux : CRIU. Il sauvegarde la mémoire des processus, la restaure ailleurs, et sa réussite dépend entièrement de ce qui tourne à l'intérieur du conteneur. Incus 7.4, annoncé le 28 août 2026 et relayé plus largement le 30, emprunte une autre voie pour les conteneurs stockés localement sur ZFS ou Btrfs. Il ne déplace pas la mémoire. Il envoie des instantanés de système de fichiers incrémentaux vers la destination pendant que le conteneur continue de tourner, et ne l'arrête que pour la synchronisation finale. La promesse est plus étroite que celle d'une vraie migration à chaud, et pour la plupart des charges elle est bien plus fiable.
The short answer
Incus 7.4 ajoute la migration quasi à chaud des conteneurs stockés localement sur ZFS ou Btrfs. Au lieu de sauvegarder la mémoire des processus avec CRIU, il envoie une série d'instantanés de système de fichiers incrémentaux vers la destination pendant que le conteneur tourne, et ne l'arrête que pour le dernier différentiel. La fonction passe par incus move avec l'option de rafraîchissement et par un mode refresh-migrate pour les évacuations de grappe. Les autres pilotes de stockage ne sont pas gérés faute de transfert d'instantanés efficace. La version ajoute aussi la gestion des bases UEFI pour les machines virtuelles, DNS NOTIFY sur les zones réseau, des limites de rafale, un moteur librbd pour Ceph RBD, et relève les versions minimales d'Open vSwitch et OVN.
Quiconque a déjà tenté d'évacuer un hôte de conteneurs sous pression connaît la forme du problème. Le système de fichiers racine pèse des dizaines de gigaoctets, la copie prend des minutes, et le conteneur reste arrêté pendant toutes ces minutes. CRIU était censé régler cela, et il y parvient parfois, mais son taux de réussite dépend de ce que la charge fait au moment précis, ce qui est une propriété détestable dans une fenêtre de maintenance.
L'astuce, c'est qu'il ne déplace pas la mémoire du tout
Incus 7.4 contourne entièrement la question. Le système de fichiers du conteneur est transféré vers le serveur cible par une série d'instantanés incrémentaux pendant que le conteneur continue de tourner. Chaque passe est plus petite que la précédente, puisqu'elle ne porte que ce qui a changé depuis l'instantané d'avant. Quand les différentiels deviennent assez petits, Incus arrête le conteneur, envoie un dernier différentiel et le démarre sur la destination.
Le conteneur s'arrête bel et bien. Les connexions tombent, les processus redémarrent, et tout ce qui conservait un état en mémoire sans le persister disparaît. Ce n'est pas un déplacement transparent et le projet ne prétend pas le contraire. Ce qui change, c'est la durée de l'arrêt : au lieu d'être proportionnelle à la taille du système de fichiers racine, elle l'est au volume de modifications survenues pendant le dernier intervalle d'instantané. Pour un étage web, un parc de travailleurs ou tout ce qui suppose déjà pouvoir redémarrer, c'est la différence entre une fenêtre de maintenance et un simple soubresaut.
On y accède par l'interface que vous employez déjà, incus move avec l'option de rafraîchissement, et un mode refresh-migrate existe pour les évacuations de grappe. C'est bien cette seconde cible qui compte. Vider un nœud avant une montée de noyau est le cas où un gel prolongé de chaque charge est à la fois le moins acceptable et le plus fréquent.
Pourquoi ZFS et Btrfs, et personne d'autre
Les deux systèmes de fichiers savent exprimer la différence entre deux instantanés sous forme de flux, à bas coût, sans relire l'ensemble du jeu de données. C'est tout le mécanisme. Les développeurs indiquent clairement que les autres pilotes de stockage ne disposent pas d'un transfert d'instantanés efficace adapté à ce type de migration : il n'y a donc pas de repli. Si vos conteneurs reposent sur du stockage en répertoire, LVM ou Ceph, vous conservez l'ancien comportement arrêt, copie, démarrage.
C'est un rappel utile au moment de choisir un moteur de stockage. La comparaison se fait généralement sur les instantanés, la compression et les sommes de contrôle, ce qui compte, mais l'ensemble des fonctions qu'un pilote de stockage rend possibles au-dessus de lui est la partie que l'on ressent trois ans plus tard. Si vous pesez encore les plateformes, notre comparatif Proxmox, ESXi et Hyper-V traite le même arbitrage côté hyperviseur, et les notes d'OpenZFS 2.4.4 décrivent ce qui bouge en dessous.
Le reste de la version, dans l'ordre de l'exploitant
Réseau. Les projets restreints peuvent désormais atteindre certains réseaux appartenant au projet par défaut via restricted.networks.access, ce qui supprime une raison courante d'accorder à un projet plus de privilèges qu'il n'en a besoin. Les zones réseau gagnent DNS NOTIFY : un serveur secondaire se rafraîchit dès qu'un enregistrement change au lieu d'attendre son compteur. On trouve aussi de nouveaux contrôles d'annonces de routeur IPv6 via ipv6.ra et des options de multidiffusion OVN supplémentaires.
Contrôle du débit. Les disques et les interfaces réseau de machines virtuelles gagnent des limites de rafale en lecture et en écriture : un plafond de débit n'a donc plus besoin de pénaliser les pics courts pour tenir une moyenne longue. Les cartes en pont, point à point et routées gagnent une queue.discipline configurable, exactement le réglage utile quand une instance bruyante remplit une file et pénalise tout ce qui partage le pont.
Stockage. Ceph RBD gagne une option pour utiliser la bibliothèque en espace utilisateur librbd plutôt que le client noyau, ce qui aligne les fonctions disponibles sur ce que la grappe propose réellement. Les réservoirs de stockage partagés en grappe se récupèrent désormais via incus admin recover, comblant une lacune qui transformait auparavant un réservoir récupérable en reconstruction.
Démarrage des machines virtuelles. Une nouvelle famille de commandes incus low-level secureboot permet de lister, ajouter, retirer, importer et exporter des entrées de base UEFI, avec des clés de configuration qui peuplent ces bases à la création d'une instance. Par ailleurs, incus start gagne une option de dérogation pour choisir une entrée de démarrage dans la NVRAM une seule fois, sans modifier l'ordre durablement. Quiconque a déjà tenté de démarrer une image de secours dans une machine virtuelle à l'ordre de démarrage têtu en verra l'intérêt.
Client. Chaque serveur distant peut désormais porter son propre certificat client via des options de certificat et de clé par distant, au lieu de partager une identité unique. La commande d'appel brut de l'API gagne des en-têtes personnalisés et la possibilité d'envoyer un fichier binaire comme corps de requête, ce qui rend accessibles depuis la ligne de commande des points d'entrée qui ne l'étaient pas.
Vérifiez trois numéros de version avant de planifier
La version minimale de Go passe à 1.26, ce qui ne concerne que ceux qui compilent Incus plutôt que d'en consommer les paquets. Les deux qui concernent tous les exploitants d'OVN sont les minimums d'Open vSwitch, désormais 3.3.0, et d'OVN lui-même, désormais 24.03.0. Ce sont des dépendances de niveau plateforme, elles proviennent généralement de votre distribution et non du dépôt Incus, et les découvrir en pleine mise à niveau est la manière classique de transformer une montée de routine en soirée prolongée.
Au-delà, le résumé honnête de 7.4 est que sa fonction phare est délibérément moins ambitieuse que ce qu'elle remplace, et qu'elle y gagne. La diffusion d'instantanés n'a pas besoin de comprendre la charge de travail. Il lui suffit que le système de fichiers sache décrire une différence, ce que ZFS et Btrfs ont toujours bien fait. C'est une surface d'erreur bien plus petite que la reconstruction d'un arbre de processus sur une autre machine, et c'est pourquoi cette version mérite une montée sur un hôte de conteneurs.
Sources et pour aller plus loin
- Incus 7.4 has been released, forum Linux Containers, 28 août 2026
- Incus 7.4 Adds Near-Live Container Migration for ZFS and Btrfs, Linuxiac, 30 août 2026
- Notes de version Incus v7.4.0, lxc/incus sur GitHub
- Migration, documentation Incus
Questions fréquentes
En quoi cela diffère-t-il d'une vraie migration à chaud ?
Une vraie migration à chaud déplace la mémoire. CRIU gèle les processus, exporte leur état, le transfère et le restaure sur la destination : en principe, rien n'est jamais arrêté longtemps. La migration quasi à chaud d'Incus 7.4 ne déplace que le système de fichiers. Elle envoie des instantanés ZFS ou Btrfs incrémentaux pendant que le conteneur continue de servir, puis l'arrête, envoie un dernier différentiel et le démarre de l'autre côté. Les connexions tombent et les processus redémarrent. Ce que vous gagnez, c'est une fenêtre de transfert dimensionnée par le dernier différentiel et non par le système de fichiers entier.
Pourquoi la limitation à ZFS et Btrfs ?
Parce que ces deux systèmes de fichiers savent calculer et diffuser la différence entre deux instantanés à bas coût, ce qui est exactement ce qu'exige un transfert incrémental. Les développeurs d'Incus expliquent que les autres pilotes de stockage n'offrent pas de mécanisme de transfert d'instantanés efficace pour cet usage : il n'y a donc rien sur quoi bâtir. Si vos conteneurs reposent sur du stockage en répertoire, LVM ou Ceph, la fonction ne vous concerne pas et vous conservez le classique arrêt, copie, démarrage.
Quelles commandes utilise-t-elle ?
Le chemin de rafraîchissement passe par la commande de déplacement existante, sous la forme incus move avec l'option de rafraîchissement, ce qui s'insère dans l'outillage que vous avez déjà bâti autour des migrations. Pour la maintenance de grappe, il existe un mode refresh-migrate destiné aux évacuations, et c'est le cas qui compte le plus en pratique : vider un nœud avant une montée de noyau sans imposer un long gel à chaque charge qu'il héberge.
Qu'est-ce qui change d'autre dans cette version ?
Beaucoup de plomberie. Les projets restreints peuvent désormais atteindre certains réseaux du projet par défaut via restricted.networks.access. Les zones réseau gagnent DNS NOTIFY, si bien que les serveurs secondaires se rafraîchissent immédiatement au lieu d'attendre l'expiration d'un compteur. Les disques et les interfaces réseau de machines virtuelles gagnent des limites de rafale en lecture et en écriture, et les cartes en pont, point à point et routées gagnent une discipline de file configurable. Ceph RBD reçoit une option de moteur librbd, et les réservoirs de stockage partagés en grappe se récupèrent désormais via incus admin recover.
Y a-t-il des prérequis de mise à niveau ?
Oui, et ce sont ceux qui mordent dans l'automatisation. La version minimale de Go passe à 1.26, ce qui compte si vous compilez Incus vous-même plutôt que de prendre les paquets de la distribution. La version minimale d'Open vSwitch passe à 3.3.0 et celle d'OVN à 24.03.0. Si vous exploitez du réseau OVN sur une version de plateforme plus ancienne, vérifiez ces deux nombres avant de planifier la mise à niveau, pas après.