Actualités¶

Incus 6.12 est maintenant disponible¶

25 avr. 2025

Introduction¶

L’équipe d’Incus est heureuse d’annoncer la sortie d’Incus 6.12 !

Cette version apporte des améliorations attendues depuis longtemps, comme l’augmentation à chaud de la mémoire des machines virtuelles, la définition d’ensembles d’adresses pour simplifier l’écriture d’ACL réseau, un nouveau système de journalisation, et plus encore !

En plus de ces nouvelles fonctionnalités, cette version propose un certain nombre d’améliorations en matière de performances, en particulier pour les systèmes comportant beaucoup de snapshots, et encore davantage d’améliorations pour ZFS.

Comme d’habitude, vous pouvez l’essayer vous-même en ligne : https://linuxcontainers.org/incus/try-it/

Nouvelles fonctionnalités¶

Ensembles d’adresses réseau¶

Pour faciliter la gestion des ACL réseau complexes, Incus prend désormais en charge la définition d’ensembles d’adresses.

Tout comme les ACL, les ensembles d’adresses sont liés à chaque projet, et chaque ensemble peut contenir un certain nombre d’adresses IPv4 et IPv6. Les ensembles peuvent ensuite être utilisés dans les ACL comme source ou comme destination.

stgraber@dakara:~$ incus network address-set create cloudflare-dns
Network address set cloudflare-dns created
stgraber@dakara:~$ incus network address-set add cloudflare-dns 1.0.0.1
stgraber@dakara:~$ incus network address-set add cloudflare-dns 1.1.1.1
stgraber@dakara:~$ incus network address-set add cloudflare-dns 2606:4700:4700::1001
stgraber@dakara:~$ incus network address-set add cloudflare-dns 2606:4700:4700::1111

stgraber@dakara:~$ incus network acl create my-acl
Network ACL my-acl created
stgraber@dakara:~$ incus network acl rule add my-acl egress action=allow state=enabled
stgraber@dakara:~$ incus network acl rule add my-acl egress action=reject state=enabled destination='$cloudflare-dns'

stgraber@dakara:~$ incus config device override d13 eth0 security.acls=my-acl
Device eth0 overridden for d13

stgraber@dakara:~$ incus exec d13 -- ping linuxcontainers.org -c1 -W1
PING linuxcontainers.org (2602:fc62:a:1::7) 56 data bytes
64 bytes from rproxy.dcmtl.stgraber.org (2602:fc62:a:1::7): icmp_seq=1 ttl=59 time=8.60 ms

--- linuxcontainers.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 8.599/8.599/8.599/0.000 ms

stgraber@dakara:~$ incus exec d13 -- ping one.one.one.one -c1 -W1
PING one.one.one.one (2606:4700:4700::1111) 56 data bytes

--- one.one.one.one ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Documentation : https://linuxcontainers.org/incus/docs/main/howto/network_address_sets/

Support du hotplug de mémoire dans les VM¶

L’un des rares points de divergence entre l’expérience utilisateur des conteneurs et des VM sous Incus était que la mémoire pouvait uniquement être réduite dans les VM, jamais augmentée.

C’est un problème désormais résolu : nous supportons à présent le hotplug de mémoire, de sorte que limits.memory puisse être augmenté à chaud, permettant aux VM d’utiliser immédiatement la RAM ajoutée.

stgraber@dakara:~$ incus launch images:debian/13 d13 --vm
Launching d13
stgraber@dakara:~$ incus exec d13 -- free -m
               total        used        free      shared  buff/cache   available
Mem:             879         238         662          19         102         640
Swap:              0           0           0
stgraber@dakara:~$ incus config set d13 limits.memory=4GiB
stgraber@dakara:~$ incus exec d13 -- free -m
               total        used        free      shared  buff/cache   available
Mem:            3951         351        3684          19         102        3600
Swap:              0           0           0

Refonte de la gestion des journaux et syslog distant¶

Jusqu’à présent, la journalisation d’Incus était limitée à deux options :

• Journalisation locale via syslog
• Journalisation distante via Loki (avec un seul endpoint)

Avec cette nouvelle version, nous avons mis en place mécanisme de journalisation bien plus flexible, permettant un nombre illimité de cibles de journalisation, via loki ou syslog, permettant de sélectionner quels événement inclure dans les journaux.

Exemple :

logging.loki01.target.type: loki
logging.loki01.target.address: https://loki01.int.example.net
logging.loki01.target.username: foo
logging.loki01.target.password: bar
logging.loki01.types: lifecycle,network-acl
logging.loki01.lifecycle.types: instance

logging.syslog01.target.type: syslog
logging.syslog01.target.address: syslog01.int.example.net
logging.syslog01.target.facility: security
logging.syslog01.types: logging
logging.syslog01.logging.level: warning

Cet exemple définit deux cibles pour les journaux, loki01 et syslog01. La première reçoit le trafic au travers d’un endpoint authentifié (reverse proxy), avec uniquement les événements liés au cycle de vie des instances et aux ACL réseau. La seconde reçoit via syslog les messages d’avertissement et de priorité supérieure.

Documentation : https://linuxcontainers.org/incus/docs/main/server_config/#server-options-logging

Support du SNAT pour les redirections réseau¶

Les redirections réseau peuvent être assez flexibles dans la manière dont les plages de ports sont autorisées.
Par exemple, vous pouvez rediriger les ports 80 et 443 externes vers une IP interne sur les ports 1234 et 2345 respectivement.

Cela fonctionne bien dans la plupart des cas, mais dans des situations spécifiques, comme les applications WebRTC utilisant des ports UDP, une partie du trafic sera initiée depuis l’instance plutôt que depuis un client externe. Dans ce scénario, le trafic sortant de l’instance depuis le port 2345 devrait apparaître à l’extérieur comme provenant de l’adresse externe sur le port 443.

La nouvelle propriété snat, qui peut être appliquée à une redirection donnée, permet de mettre en place un tel comportement. Elle définit une règle de SNAT pour le trafic provenant d’une instance.

La fonctionnalité est limitée aux redirections sur des bridges standards (OVN n’est pas supporté), et uniquement sur les systèmes utilisant nftables pour les règles de pare-feu.

Documentation: https://linuxcontainers.org/incus/docs/main/howto/network_forwards/#port-properties

Authentification via le paramètre access_token¶

Incus supporte deux mécanismes d’authentification :

• Via des certificats client TLS
• Via OpenID Connect (OIDC)

En ce qui concerne les certificats client TLS, la plupart des clients se servent directement du certificat utilisé dans la connexion TLS. Cependant, cela ne fonctionne pas toujours, soit parce que le client a du mal à le gérer (par exemple, un navigateur web), soit parce qu’un proxy terminant la connexion TLS est présent dans la chaîne.

Pour cette raison, nous supportons l’utilisation d’un jeton signé Bearer dérivé du certificat TLS, dans l’en-tête HTTP Authorization.

Dans cette nouvelle version, ce même jeton Bearer peut être passé dans le paramètre d’URL access_token plutôt que dans l’en-tête HTTP.

Cela permet à des clients web tels que l’API websocket de JavaScript de se connecter à des endpoints websocket authentifiés, lorsque ceux-ci ne prennent pas en charge l’utilisation d’en-têtes HTTP personnalisés.

Exemple :

stgraber@dakara:~$ curl -k -s https://127.0.0.1:8443/1.0 | jq -r .metadata.auth
untrusted
stgraber@dakara:~$ curl -k -s https://127.0.0.1:8443/1.0?access_token=eyJhbGciOiJFUzM4NCIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZjQ3MzRhYzY3YzAzMDYxY2Y1Yzg5Y2UxYTQ2NDAwYjc4MzQ2MWRiOGI3MjlkMDhjNDZhYjE5MmM3ZDc2NTMxIiwiZXhwIjoxNzQ1NTMxOTA4LCJuYmYiOjE3NDU1MzE4NDgsImlhdCI6MTc0NTUzMTg0OH0.WcsG48XQ41fNhLUlf-nqwAyJrZKpCrfM-W8mOSNpt7cwPH-QhKZkiBDa3sFWIVOdo15_cOZBeNy1QbJu6rCnYYQ18LpNJNkSKPkcwi65-yBo7U7ync5BQCuhsOgxAQap | jq -r .metadata.auth
trusted

Meilleur support du filtrage côté serveur dans la CLI¶

Nous avons récemment ajouté le support du filtrage côté serveur pour tous les objets dans l’API d’Incus. Pour continuer dans cette lancée, nous sommes en train petit à petit d’ajouter le support pour ce filtrage dans la CLI, permettant de réduire les accès à la base de données et le trafic réseau lorsque seuls certains éléments sont demandés.

Dans cette version, les objets suivants supportent à présent le filtrage côté serveur :

• Instances
• Images
• Volumes personnalisés
• Profils

Exemple :

stgraber@dakara:~$ incus profile list description=bar
+------+-------------+---------+
| NAME | DESCRIPTION | USED BY |
+------+-------------+---------+
| foo  | bar         | 0       |
+------+-------------+---------+

Ce travail a été en partie mené par des étudiants de l’Université du Texas à Austin.

Davantage de documentation automatiquement générée¶

Nous avons poursuivi nos efforts pour porter la plupart de nos tables de configuration afin qu’elles soient générées directement à partir du code, évitant ainsi tout risque d'oubli de clefs de configuration.

Dans cette version, la documentation de la configuration des objets suivants est désormais générée automatiquement :

• Bridges réseau
• Redirections réseau
• Périphériques TPM
• Périphériques proxy
• Périphériques GPU
• Interfaces réseau
• Périphériques Infiniband

Ce travail a été mené par des étudiants de l’Université du Texas à Austin.

Liste complète des changements¶

Voici une liste complète de tous les changements apportés par cette version :

Documentation¶

La documentation d’Incus peut être consultée sur :
https://linuxcontainers.org/incus/docs/main/

Paquets¶

Incus ne fournit pas de paquet d’installation mais bien un tarball à chaque version. Vous trouverez ci-dessous différentes solutions pour mettre Incus en service.

Installation du serveur Incus sous Linux¶

Incus est disponible sur la plupart des distributions Linux courantes. Vous trouverez des instructions d’installation détaillées dans notre documentation.

https://linuxcontainers.org/incus/docs/main/installing/

Paquet Homebrew du client Incus¶

Le client Incus est disponible sur Homebrew pour Linux et macOS.

https://formulae.brew.sh/formula/incus

Paquet Chocolatey du client Incus¶

Le client Incus est disponible sur Chocolatey pour les utilisateurs de Windows.

https://community.chocolatey.org/packages/incus/6.12.0

Paquet Winget du client Incus¶

Le client Incus est aussi disponible sur Winget pour les utilisateurs de Windows.

https://winstall.app/apps/LinuxContainers.Incus

Support¶

Les versions de fonctionnalité d’Incus ne sont supportées que jusqu’à la sortie de la suivante. Les personnes souhaitant un support plus long et des changements moins fréquents devraient plutôt envisager d’utiliser Incus 6.0 LTS.

Le support communautaire est disponible sur : https://discuss.linuxcontainers.org
Un support commercial est disponible sur : https://zabbly.com/incus
Les bugs peuvent être signalés sur : https://github.com/lxc/incus/issues

Incus 6.0.4 LTS est maintenant disponible¶

4 avr. 2025

Introduction¶

L’équipe d’Incus est heureuse d’annoncer la sortie d’Incus 6.0.4 !

Il s’agit de la quatrième version apportant des corrections de bugs pour Incus 6.0, dont le support est assuré jusqu’en juin 2029

Changements¶

Comme d’habitude, cette version se concentre sur la stabilité et le hardening.

Des améliorations mineures ont également été rétroportées, en particulier tout ce qui ne nécessite pas de migrations de données, de modifications dans la base de données, ou ne cause pas de changements inattendus dans le comportement observé par l’utilisateur.

Le nombre de ces améliorations pour la branche LTS est amené à diminuer avec le temps.

Les points marquants de cette version sont :

• ACL réseau par instance pour les réseaux de type bridge
• Scriptlets QEMU améliorés
• Dumps de mémoire pour les VM
• Informations supplémentaires sur l’état des réseaux OVN
• Amélioration du fichier de preseed du serveur
• Support de ACME DNS-01
• Support du provisionnement des VM via SMBIOS11
• Support de l’IOMMU pour les VM
• Support des VRF pour les cartes réseau routées
• Nouvelle plage d’adresses MAC
• Cartes réseau USB pour les VM
• Disques USB pour les VM
• Serveurs DNS configurables par réseau
• Routes IPv4 supplémentaires en DHCP

La liste complète des commits est présentée ci-dessous :

Avis pour les packagers : Incus utilise à présent l’outil externe lego pour la gestion du protocole ACME, plutôt que d’en intégrer la logique dans le binaire incusd. Veuillez prendre en compte cette dépendance si vous souhaitez préserver le support des certificats via ACME.

Support et mise à niveau¶

La branche Incus 6.0 est supportée jusqu’en juin 2029. Il est toujours fortement recommandé d’utiliser la dernière version de correction de bugs.

Téléchargements¶

• Tarball d’Incus : incus-6.0.4.tar.xz
• Signature GPG : incus-6.0.4.tar.xz.asc

Remerciements¶

Cette version LTS a été rendue possible grâce au financement du Sovereign Tech Fund (qui fait maintenant partie de la Sovereign Tech Agency).

Le Sovereign Tech Fund soutient le développement, l'amélioration et la maintenance des infrastructures numériques ouvertes. Son objectif est de renforcer durablement l'écosystème open source, en mettant l'accent sur la sécurité, la résilience, la diversité technologique et les personnes qui sont derrière le code.

Pour en savoir plus, consultez https://www.sovereign.tech

Incus 6.11 est maintenant disponible¶

28 mars 2025

Introduction¶

L’équipe d’Incus est heureuse d’annoncer la sortie d’Incus 6.11 !

La fonctionnalité phare de cette version est sans aucun doute la prise en charge initiale de LINSTOR comme nouveau driver de stockage pour les personnes cherchant une alternative à Ceph !
Mais c’est loin d’être la seule nouveauté de cette version, avec un grand nombre de fonctionnalités pour les VM, les conteneurs d’application, et le réseau.

Comme d’habitude, vous pouvez l’essayer vous-même en ligne : https://linuxcontainers.org/incus/try-it/

Nouvelles fonctionnalités¶

Driver de stockage LINSTOR¶

Incus supporte à présent LINSTOR comme alternative à Ceph pour le stockage en cluster.
Vous pouvez en apprendre plus sur LINSTOR sur leur site web : https://linbit.com/linstor/

En résumé, LINSTOR est une couche logicielle reposant sur DRBD, permettant la réplication de périphériques en mode bloc entre plusieurs serveurs.

Cela permet aux volumes en bloc d’être créés pour les conteneurs et les machines virtuelles, avec une copie primaire présente typiquement sur le serveur sur lequel l’instance tourne, et une copie répliquée présente sur un autre serveur du cluster.

Documentation du driver : https://linuxcontainers.org/incus/docs/main/reference/storage_linstor/
Guide d’utilisation : https://linuxcontainers.org/incus/docs/main/howto/storage_linstor_setup/
Documentation technique : https://linuxcontainers.org/incus/docs/main/reference/storage_linstor_internals/

Nouvelle plage d’adresses MAC¶

LXC et Incus utilisaient tous deux jusqu’à présent la plage d’adresses MAC 00:16:3e.

Cette plage était en réalité allouée au projet Xen et, bien qu’il n’y ait pas de risque de collision avec des adresses MAC de périphériques physiques, celle-ci ne permettait pas de distinguer facilement entre des instances LXC/Incus et des instances Xen.

Pour rendre cela plus propre, Zabbly a obtenu de l’IEEE une plage d’adresses MAC pour un usage par LXC et Incus, 10:66:6a.

La nouvelle plage sera automatiquement utilisée pour les instances et réseaux nouvellement créés.
Les instances et les réseaux existants restent inchangés.

Cartes réseau USB pour les VM¶

Une nouvelle clef de configuration, io.bus, a été ajoutée pour les interfaces réseau des VM.
Elle peut prendre deux valeurs : virtio (par défaut) et usb.

En définissant io.bus=usb, l’interface réseau apparaîtra comme un adaptateur réseau USB générique plutôt qu’un périphérique PCI.

Cela devrait permettre à certains anciens OS invités d’accéder au réseau, ainsi qu’aux plus récents de se connecter à Internet pour récupérer les drivers VirtIO avant de retourner sur le bus virtio par défaut.

Documentation : https://linuxcontainers.org/incus/docs/main/reference/devices_nic/

Disques USB pour les VM¶

Il est maintenant également possible d’attacher des disques aux VM via un bus USB.
Ce faisant, les disques apparaîtront comme des périphériques de stockage de masse USB.

Pour utiliser la fonctionnalité, il faut définir io.bus=usb sur le périphérique disque.

Documentation : https://linuxcontainers.org/incus/docs/main/reference/devices_disk/

Suivi des définitions des machines QEMU¶

Incus garde désormais en mémoire la définition des machines QEMU au démarrage des VM, permettant la migration à chaud entre plusieurs versions de QEMU dès lors que le service QEMU cible est au moins aussi récent que le service source.

Cela se fait par l’intermédiaire d’une nouvelle clef de configuration, volatile.vm.definition.

Configuration du point d’entrée pour les conteneurs OCI¶

Il est désormais possible de configurer le point d’entrée des conteneurs OCI.

À la création d’un conteneur OCI, le point d’entrée est extrait de la configuration OCI et est transformé en clefs de configuration du conteneur.

Les clefs de configuration sont les suivantes :

• oci.entrypoint
• oci.cwd
• oci.uid
• oci.gid

Celles-ci peuvent être modifiées à la création de l’instance, ou changées par la suite.

stgraber@castiana:~$ incus launch oci-docker:nginx nginx
Launching nginx
stgraber@castiana:~$ incus config show nginx | grep oci\\.
  oci.cwd: /
  oci.entrypoint: /docker-entrypoint.sh nginx -g 'daemon off;'
  oci.gid: "0"
  oci.uid: "0"

Documentation : https://linuxcontainers.org/incus/docs/main/reference/instance_options/

Accès à l’ICMP (ping) dans les conteneurs OCI pour les utilisateurs non privilégiés¶

Les conteneurs OCI peuvent désormais envoyer des paquets ICMP en tant qu’utilisateurs ordinaires.
Les conteneurs d’application étant conçus pour exécuter une seule application, il n’y a pas grand intérêt à restreindre les pings au seul utilisateur root.

Accès aux ports privilégiés dans les conteneurs OCI pour les utilisateurs non privilégiés¶

Les conteneurs OCI peuvent désormais utiliser les ports privilégiés en tant qu’utilisateurs ordinaires.
Les conteneurs d’épplication étant conçus pour exécuter une seule application, il n’y a pas grand intérêt à restreindre les ports privilégiés au seul utilisateur root.

Temps CPU alloué dans l’API de consultation de l’état des instances¶

Une nouvelle valeur allocated_time est exposée dans l’API permettant de consulter l’état des instances.
Elle donne combien de temps CPU (en nanosecondes) peut être utilisé par seconde par l’instance, au maximum de ses capacités allouées.

Cela permet de calculer un pourcentage d’utilisation CPU lorsque cette valeur est combinée avec plusieurs mesures de l'utilisation CPU sur une période de temps donnée.

stgraber@castiana:~$ incus query /1.0/instances/nginx/state | jq .cpu
{
  "allocated_time": 1000000000,
  "usage": 163062000
}

Configuration des serveurs DNS¶

Une nouvelle option de configuration, dns.nameservers, est désormais disponibles pour les réseaux bridge et ovn.

Cela peut être utile lorsqu’un ensemble de résolveurs DNS dédiés doivent être utilisés par l’intégralité des instances, ou dans des environnements dans lesquels certains réseaux doivent ignorer la résolution locale pour utiliser des résolveurs publics.

Documentation (bridge) : https://linuxcontainers.org/incus/docs/main/reference/network_bridge/
Documentation (OVN) : https://linuxcontainers.org/incus/docs/main/reference/network_ovn/

Routes IPv4 supplémentaires en DHCP¶

Une nouvelle option de configuration, ipv4.dhcp.routes, est désormais disponible sur les réseaux bridge et ovn. Elle permet d’annoncer des routes supplémentaires en DHCP.

Documentation (bridge) : https://linuxcontainers.org/incus/docs/main/reference/network_bridge/
Documentation (OVN) : https://linuxcontainers.org/incus/docs/main/reference/network_ovn/

Configuration de l’expiration des baux DHCP en IPv4 pour OVN¶

L’option de configuration ipv4.dhcp.expiry est à présent aussi disponible pour les réseaux OVN.
Elle permet de réduire ou d’étendre la durée par défaut des baux DHCP.

Documentation : https://linuxcontainers.org/incus/docs/main/reference/network_ovn/

Extension de l’état des réseaux pour inclure le nom du switch local OVN¶

Le nom du switch local OVN fait désormais partie des informations réseau OVN.
Cela simplifie le débogage, en particulier pour des réseaux isolés (sans uplink) ou qui n’ont pas de routeur logique.

root@server01:~# incus network info default
Name: default
MAC address: 00:16:3e:54:62:a9
MTU: 1500
State: up
Type: broadcast

IP addresses:
  inet  10.104.61.1/24 (link)
  inet6 fd42:73ae:9013:c530::1/64 (link)

OVN:
  Chassis: server01
  Logical router: incus-net20-lr
  Logical switch: incus-net20-ls-int
  IPv4 uplink address: 172.31.254.10
  IPv6 uplink address: fd00:1e4d:637d:1234:216:3eff:fe54:62a9

Avis pour les packagers¶

Dans cette version, Incus utilise l’outil externe lego pour la gestion du protocole ACME.
Cela a pour effet de réduire significativement la taille du binaire d’Incus, mais l’outil lego devient donc une dépendance qu’il s’agirait de déclarer comme telle.

Liste complète des changements¶

Voici une liste complète de tous les changements apportés par cette version :

Documentation¶

La documentation d’Incus peut être consultée sur :
https://linuxcontainers.org/incus/docs/main/

Paquets¶

Incus ne fournit pas de paquet d’installation mais bien un tarball à chaque version. Vous trouverez ci-dessous différentes solutions pour mettre Incus en service.

Installation du serveur Incus sous Linux¶

Incus est disponible sur la plupart des distributions Linux courantes. Vous trouverez des instructions d’installation détaillées dans notre documentation.

https://linuxcontainers.org/incus/docs/main/installing/

Paquet Homebrew du client Incus¶

Le client Incus est disponible sur Homebrew pour Linux et macOS.

https://formulae.brew.sh/formula/incus

Paquet Chocolatey du client Incus¶

Le client Incus est disponible sur Chocolatey pour les utilisateurs de Windows.

https://community.chocolatey.org/packages/incus/6.11.0

Paquet Winget du client Incus¶

Le client Incus est aussi disponible sur Winget pour les utilisateurs de Windows.

https://winstall.app/apps/LinuxContainers.Incus

Support¶

Les versions de fonctionnalité d’Incus ne sont supportées que jusqu’à la sortie de la suivante. Les personnes souhaitant un support plus long et des changements moins fréquents devraient plutôt envisager d’utiliser Incus 6.0 LTS.

Le support communautaire est disponible sur : https://discuss.linuxcontainers.org
Un support commercial est disponible sur : https://zabbly.com/incus
Les bugs peuvent être signalés sur : https://github.com/lxc/incus/issues

Incus 6.10 est maintenant disponible¶

28 févr. 2025

Introduction¶

L’équipe d’Incus est heureuse d’annoncer la sortie d’Incus 6.10 !

Cette version simplifie l’utilisation d’Incus avec des certificats HTTPS valides, ajoute une nouvelle façon d’envoyer des données de provisionnement aux VM, améliore l’API, et plus encore !

Comme d’habitude, vous pouvez l’essayer vous-même en ligne : https://linuxcontainers.org/incus/try-it/

Nouvelles fonctionnalités¶

Validation ACME DNS-01¶

De nouvelles clefs de configuration ont été ajoutées pour permettre l’utilisation du challenge DNS-01 avec ACME (le plus souvent pour des certificats Let’s Encrypt).

Cela peut simplifier le déploiement de certificats TLS valides sur des serveurs Incus.

Exemple de configuration :

acme.agree_tos: true
acme.domain: foo.example.net
acme.email: admin@foo.example.net
acme.challenge: DNS-01
acme.provider: cloudflare
acme.provider.environment: |-
  CLOUDFLARE_EMAIL=admin@foo.example.net
  CLOUDFLARE_API_KEY=XYZ

Documentation : https://linuxcontainers.org/incus/docs/main/server_config/#server-options-acme

Support du filtrage sur toute l’API¶

Incus supportait dans les précédentes versions le filtrage côté serveur des instances, des images, et des volumes de stockage.
La même logique de filtrage a maintenant été étendue à toutes les autres collections de l’API.

Celles-ci supportent donc le paramètre filter, avec les mêmes filtres ODdata.
Le client Incus en ligne de commande sera mis à jour dans les versions qui viennent pour prendre en charge le filtrage sur les nouvelles collections filtrables.

Documentation : https://linuxcontainers.org/incus/docs/main/rest-api/#filtering

Support du provisionnement des VM via SMBIOS11¶

Sur les systèmes disposant d’une table DMI (x86_64 ou aarch64), il est désormais possible de transmettre des données via la table SMBIOS Type 11. Cela permet à l’hyperviseur de fournir des données au système sans faire appel à un canal de communication séparé (réseau, série…).

Cette fonctionnalité est notamment prise en charge par systemd, qui peut l’utiliser pour lire des données de provisionnement : https://www.freedesktop.org/software/systemd/man/latest/smbios-type-11.html

Exemple :

stgraber@dakara:~$ incus launch images:debian/12 d12 --vm -c smbios11.io.systemd.credential:foo=bar
Launching d12
stgraber@dakara:~$ incus exec d12 -- systemd-creds --system cat foo
bar

Support de l’IOMMU dans les VM¶

Les VM Incus supportent désormais automatiquement l’IOMMU, ce qui améliore la sécurité et le passthrough des périphériques. Ce changement est complètement invisible dans la majorité des cas.

root@u1:~# dmesg | grep -i iommu
[    0.406474] iommu: Default domain type: Translated
[    0.406481] iommu: DMA domain TLB invalidation policy: strict mode
[    0.534812] virtio_iommu virtio0: input address: 48 bits
[    0.534820] virtio_iommu virtio0: page mask: 0xfffffffffffff000
[    0.637345] pcieport 0000:00:02.0: Adding to iommu group 0
[    0.642755] pcieport 0000:00:02.1: Adding to iommu group 1
[    0.649614] pcieport 0000:00:02.2: Adding to iommu group 2
[    0.656700] pcieport 0000:00:02.3: Adding to iommu group 3
[    0.663517] pcieport 0000:00:02.4: Adding to iommu group 4
[    0.669419] pcieport 0000:00:02.5: Adding to iommu group 5
[    0.675831] pcieport 0000:00:02.6: Adding to iommu group 6
[    0.682967] pcieport 0000:00:02.7: Adding to iommu group 7
[    0.688303] pcieport 0000:00:03.0: Adding to iommu group 8
[    0.695646] pcieport 0000:00:03.1: Adding to iommu group 9
[    0.700994] pcieport 0000:00:03.2: Adding to iommu group 10
[    0.709613] pcieport 0000:00:03.3: Adding to iommu group 11
[    0.715130] pcieport 0000:00:03.4: Adding to iommu group 12
[    0.722208] virtio-pci 0000:01:00.0: Adding to iommu group 13
[    0.728419] virtio-pci 0000:01:00.1: Adding to iommu group 13
[    0.732362] virtio-pci 0000:01:00.2: Adding to iommu group 13
[    0.737953] virtio-pci 0000:01:00.3: Adding to iommu group 13
[    0.746652] virtio-pci 0000:01:00.4: Adding to iommu group 13
[    0.752491] virtio-pci 0000:01:00.5: Adding to iommu group 13
[    0.781052] virtio-pci 0000:02:00.0: Adding to iommu group 14
[    0.791255] virtio-pci 0000:03:00.0: Adding to iommu group 15
[    0.799383] virtio-pci 0000:03:00.1: Adding to iommu group 15
[    0.809692] virtio-pci 0000:04:00.0: Adding to iommu group 16
[    0.820005] virtio-pci 0000:05:00.0: Adding to iommu group 17
[    1.399721] xhci_hcd 0000:01:00.6: Adding to iommu group 13

Support des VRF pour les cartes réseau routées¶

Les systèmes utilisant plusieurs VRF (Virtual Routing and Forwarding) peuvent à présent connecter les cartes réseau en mode routed à la VRF de leur choix.

Cela se fait avec une nouvelle propriété vrf sur les périphériques nic de type routed.

Documentation : https://linuxcontainers.org/incus/docs/main/reference/devices_nic/#nictype-routed

Création de profils dans un projet via un preseed¶

La logique de preseed d’Incus a été étendue pour permettre la création de profils dans des projets définis.

Pour ce faire, il suffit de définir la clef project dans l’entrée profile correspondante.
Le projet devra également être défini dans le preseed.

Documentation : https://linuxcontainers.org/incus/docs/main/howto/initialize/#configuration-format

Support de LZ4 pour les sauvegardes et les images¶

Le format de compression lz4 est à présent pris en charge dans Incus.
Si l’outil correspondant est installé sur le système, il est désormais possible d’utiliser LZ4 pour les sauvegardes d’instances, de volumes et de buckets (import/export), ainsi que pour les images.

Liste complète des changements¶

Voici une liste complète de tous les changements apportés par cette version :

Documentation¶

La documentation d’Incus peut être consultée sur :
https://linuxcontainers.org/incus/docs/main/

Paquets¶

Incus ne fournit pas de paquet d’installation mais bien un tarball à chaque version. Vous trouverez ci-dessous différentes solutions pour mettre Incus en service.

Installation du serveur Incus sous Linux¶

Incus est disponible sur la plupart des distributions Linux courantes. Vous trouverez des instructions d’installation détaillées dans notre documentation.

https://linuxcontainers.org/incus/docs/main/installing/

Paquet Homebrew du client Incus¶

Le client Incus est disponible sur Homebrew pour Linux et macOS.

https://formulae.brew.sh/formula/incus

Paquet Chocolatey du client Incus¶

Le client Incus est disponible sur Chocolatey pour les utilisateurs de Windows.

https://community.chocolatey.org/packages/incus/6.10.0

Paquet Winget du client Incus¶

Le client Incus est aussi disponible sur Winget pour les utilisateurs de Windows.

https://winstall.app/apps/LinuxContainers.Incus

Support¶

Les versions de fonctionnalité d’Incus ne sont supportées que jusqu’à la sortie de la suivante. Les personnes souhaitant un support plus long et des changements moins fréquents devraient plutôt envisager d’utiliser Incus 6.0 LTS.

Le support communautaire est disponible sur : https://discuss.linuxcontainers.org
Un support commercial est disponible sur : https://zabbly.com/incus
Les bugs peuvent être signalés sur : https://github.com/lxc/incus/issues

Incus 6.9 est maintenant disponible¶

24 janv. 2025

Introduction¶

Bonne année !

L’équipe d’Incus est heureuse d’annoncer la sortie d’Incus 6.9 !

Il s’agit d’une version un peu plus légère en raison des vacances, mais elle offre tout de même quelques fonctionnalités supplémentaires intéressantes en plus de la dose habituelle de corrections de bugs.

Comme d’habitude, vous pouvez l’essayer vous-même en ligne : https://linuxcontainers.org/incus/try-it/

Nouvelles fonctionnalités¶

ACL réseau par instance pour les réseaux de type bridge¶

Les ACL réseau peuvent maintenant être directement appliquées aux instances tournant sur un réseau managé de type bridge, si le système utilise nft pour ses règles de pare-feu (cela peut être vérifié avec incus info).

Cela permet de faire de la micro-segmentation réseau en permettant à des instances sur le même bridge d’avoir des règles de pare-feu individuelles en ingress/egress.

Les ACL réseau peuvent être créées et gérées avec incus network acl, puis appliquées aux interfaces réseau idoines en utilisant la clef de configuration security.acls.

Documentation des ACL : https://linuxcontainers.org/incus/docs/main/howto/network_acls/
Documentation des bridges : https://linuxcontainers.org/incus/docs/main/reference/network_bridge/
Documentation des interfaces réseau : https://linuxcontainers.org/incus/docs/main/reference/devices_nic/#nic-bridged

Améliorations du scriptlet QEMU¶

Le scriptlet QEMU a été davantage amélioré dans cette version.

Tous les appels du scriptlet fournissent désormais un objet décrivant l’instance, permettant d’accéder à sa configuration, aux profils qu’elle utilise…

Un nouveau hook config, qui est lancé avant le démarrage de QEMU, a également été ajouté.
Ce hook ne peut pas être utilisé pour envoyer des commandes QMP, mais il permet d’appeler de nouvelles fonctions pour modifier la configuration (arguments en ligne de commande ou fichier .conf) de QEMU :

• get_qemu_cmdline
• set_qemu_cmdline
• get_qemu_conf
• set_qemu_conf

Documentation: https://linuxcontainers.org/incus/docs/main/reference/instance_options/#advanced-use

Dumps de mémoire pour les VM¶

Une nouvelle commande incus debug memory-dump et son API associée ont été ajoutées pour fournir un moyen simple de récupérer un dump mémoire d’une machine virtuelle.

Les VM Incus exposent désormais un périphérique additionnel permettant aux instances Windows de fournir des informations de débogage mémoire et de produire un dump mémoire chargeable dans le débogueur Windows.

stgraber@dakara:~$ incus launch images:debian/12 v1 --vm
Launching v1
stgraber@dakara:~$ incus debug dump-memory v1 debug --format=elf
stgraber@dakara:~$ file debug
debug: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style

Récupération des adresses d’uplink des réseaux OVN¶

Il est désormais possible de récupérer les adresses IPv4 et IPv6 d’uplink directement depuis incus network info.

stgraber@athos:~# incus network info default
Name: default
MAC address: 00:16:3e:8d:51:b6
MTU: 1500
State: up
Type: broadcast

IP addresses:
  inet   10.22.45.1/24 (link)
  inet6  2602:fc62:b:8006::1/64 (link)

Network usage:
  Bytes received: 0B
  Bytes sent: 0B
  Packets received: 0
  Packets sent: 0

OVN:
  Chassis: delmak
  Logical router: incus-net13-lr
  IPv4 uplink address: 172.17.200.106
  IPv6 uplink address: 2602:fc62:b:200::106

Création de volumes de stockage depuis le fichier de preseed du serveur¶

Il est maintenant possible de définir des volumes de stockage initiaux directement dans le fichier de preseed du serveur.
Cette fonctionnalité est pratique pour notamment définir des volumes partagés et des profils qui les utilisent, le tout dans le fichier de preseed. Il est également possible de définir des volumes pour les images Incus ou le stockage des sauvegardes.

Documentation : https://linuxcontainers.org/incus/docs/main/howto/initialize/#configuration-format

Ajout d’une description dans les commandes create¶

Toutes les commandes create ont à présent une option --description qui peut être utilisée pour définir la description de l’objet créé.

stgraber@dakara:~$ incus profile create foo --description "Example profile"
Profile foo created
stgraber@dakara:~$ incus profile list
+---------+-----------------------+---------+
|  NAME   |      DESCRIPTION      | USED BY |
+---------+-----------------------+---------+
| default | Default Incus profile | 6       |
+---------+-----------------------+---------+
| foo     | Example profile       | 0       |
+---------+-----------------------+---------+

Liste complète des changements¶

Voici une liste complète de tous les changements apportés par cette version :

Documentation¶

La documentation d’Incus peut être consultée sur :
https://linuxcontainers.org/incus/docs/main/

Paquets¶

Incus ne fournit pas de paquet d’installation mais bien un tarball à chaque version. Vous trouverez ci-dessous différentes solutions pour mettre Incus en service.

Installation du serveur Incus sous Linux¶

Incus est disponible sur la plupart des distributions Linux courantes. Vous trouverez des instructions d’installation détaillées dans notre documentation.

https://linuxcontainers.org/incus/docs/main/installing/

Paquet Homebrew du client Incus¶

Le client Incus est disponible sur Homebrew pour Linux et macOS.

https://formulae.brew.sh/formula/incus

Paquet Chocolatey du client Incus¶

Le client Incus est disponible sur Chocolatey pour les utilisateurs de Windows.

https://community.chocolatey.org/packages/incus/6.9.0

Paquet Winget du client Incus¶

Le client Incus est aussi disponible sur Winget pour les utilisateurs de Windows.

https://winstall.app/apps/LinuxContainers.Incus

Support¶

Les versions de fonctionnalité d’Incus ne sont supportées que jusqu’à la sortie de la suivante. Les personnes souhaitant un support plus long et des changements moins fréquents devraient plutôt envisager d’utiliser Incus 6.0 LTS.

Le support communautaire est disponible sur : https://discuss.linuxcontainers.org
Un support commercial est disponible sur : https://zabbly.com/incus
Les bugs peuvent être signalés sur : https://github.com/lxc/incus/issues

Anciennes nouvelles¶

• 19 déc. 2024
• 13 déc. 2024
• 15 nov. 2024
• 3 oct. 2024
• 17 sept. 2024
• 6 sept. 2024
• 9 août 2024
• 12 juil. 2024
• 28 juin 2024
• 31 mai 2024
• 7 mai 2024
• 4 avr. 2024
• 26 mars 2024
• 23 févr. 2024
• 29 janv. 2024
• 26 janv. 2024
• 21 déc. 2023
• 27 nov. 2023
• 28 oct. 2023
• 7 oct. 2023