Actualités¶

Incus 6.15 est maintenant disponible¶

1 août 2025

Introduction¶

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

Cette nouvelle version apporte des améliorations un peu partout, que ce soit pour les conteneurs d’application, les VM, le clustering, le réseau, ou encore l’outil en ligne de commande.

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

Ajoutons que nous avons fait de gros progrès sur Incus OS, et l’utilisons à présent pour faire tourner l’environnement de démonstration. Nous avons également conçu un outil de téléchargement, avec des instructions disponibles ici.

Nouvelles fonctionnalités¶

Support de l’authentification pour les registres OCI¶

Incus supporte désormais l’utilisation de modules d’authentification pour interagir avec les registres OCI. Les modules peuvent être spécifiés par l’intermédiaire de la nouvelle option --credentials-helper dans la commande incus remote add.

stgraber@dakara:~$ incus remote add oci-demo https://northamerica-northeast1-docker.pkg.dev/stgraber-1525358518329/test-registry --protocol=oci --credentials-helper=docker-credential-gcloud·
stgraber@dakara:~$ incus image info oci-demo:alpine:latest
Fingerprint: ec1b05d1eac264d9204a57f4ad9d4dc35e9e756e9fedaea0674aefc7edb1d6a4
Size: 3.47MiB
Architecture: x86_64
Type: container
Public: yes
Timestamps:
    Created: 2025/02/13 22:28 EST
    Uploaded: 2025/02/13 22:28 EST
    Expires: never
    Last used: never
Properties:
    description: northamerica-northeast1-docker.pkg.dev/stgraber-1525358518329/test-registry/alpine (OCI)
    id: alpine:latest
    type: oci
    architecture: x86_64
Aliases:
    - alpine:latest
Cached: no
Auto update: disabled
Profiles: []

Utilisation de webhooks comme cibles de journalisation¶

Nous avons récemment retravaillé notre système de journalisation pour supporter l’ajout de plusieurs cibles, avec divers filtres, et avons ajouté le support de la journalisation par l’intermédiaire de syslog, en plus du support préexistant pour loki.

Dans cette version, nous ajoutons un nouveau type de cible : les webhooks.
Le système supporte les mêmes fonctionnalités que pour les deux autres types de cibles, et envoie les événements en JSON à la cible webhook. La syntaxe JSON est la même que celle utilisée dans notre API d’événements.

stgraber@dakara:~$ incus config set logging.demo.target.address=http://127.0.0.1:8080/hook
stgraber@dakara:~$ incus config set logging.demo.target.type=webhook

Suite à cela, le serveur cible reçoit les événements ainsi :

POST /hook (application/json, 231 bytes)
{"type":"lifecycle","timestamp":"2025-07-31T23:34:12.714974583-04:00","metadata":{"action":"config-updated","source":"/1.0","requestor":{"username":"stgraber","protocol":"unix","address":"@"}},"location":"none","project":"default"}

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

Meilleur contrôle du hotplug mémoire¶

Il y a quelques versions, nous avons ajouté le support du hotplug mémoire dans les machines virtuelles.
Cette fonctionnalité entraînait une certaine difficulté à déterminer la quantité maximale de mémoire qu’une VM peut recevoir en hotplug.

Cela est assez complexe, puisque nous nous confrontons à des limites physiques (les tailles des adresses mémoire physiques et virtuelles), ainsi qu’à un certain coût difficilement prédictible. Nous avons fait quelques ajustements dans la logique de hotplug au cours des dernières versions, et sommes arrivés à quelque chose qui semble fonctionner correctement dans la grande majorité des cas.

Cela dit, ils est apparu qu’avoir plus de contrôle sur la quantité de mémoire qui peut être ajoutée à chaud, et même permettre de désactiver la fonctionnalité dans certains cas, pouvait être une bonne idée.

Nous avons donc ajouté la clef de configuration limits.memory.hotplug, correspondant à la quantité maximale de mémoire (incluant la mémoire rajoutée à chaud) qu’une VM peut avoir. La valeur 0 désactive complètement la fonctionnalité.

stgraber@dakara:~$ incus config set d13 limits.memory.hotplug=0
stgraber@dakara:~$ incus start d13
stgraber@dakara:~$ incus config set d13 limits.memory=2GiB
Error: Failed updating memory limit: Memory hotplug feature is disabled

Documentation : https://linuxcontainers.org/incus/docs/main/reference/instance_options/#instance-resource-limits:limits.memory.hotplug

Persistance de l’éjection des CD-ROM dans les VM¶

Nous gardons désormais en mémoire le fait qu’un CD-ROM a été éjecté par l’OS invité.
Cela se fait par l’intermédiaire de la nouvelle propriété attached pour les périphériques de type disk, qui est automatiquement définie à false à l’éjection de ceux-ci.

stgraber@dakara:~$ incus config device add d13 virtio disk pool=default source=virtio-drivers
Device virtio added to d13

stgraber@dakara:~$ incus config show d13
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Debian trixie amd64 (20250731_05:24)
  image.os: Debian
  image.release: trixie
  image.serial: "20250731_05:24"
  image.type: disk-kvm.img
  image.variant: default
  volatile.base_image: 340aab0e87de46062c1363cab4beb7d30d0474adceca5bf450b5162d8c2cc2c5
  volatile.cloud-init.instance-id: 5a79a550-143d-4db0-a223-74191e968ea3
  volatile.eth0.host_name: tap8ca1eb54
  volatile.eth0.hwaddr: 10:66:6a:8e:8e:93
  volatile.last_state.power: RUNNING
  volatile.uuid: af7f680b-7824-47ca-be9a-9189881ade90
  volatile.uuid.generation: af7f680b-7824-47ca-be9a-9189881ade90
  volatile.vm.definition: pc-q35-10.0
  volatile.vm.rtc_adjustment: "0"
  volatile.vm.rtc_offset: "-1"
  volatile.vsock_id: "1524898578"
devices:
  virtio:
    pool: default
    source: virtio-drivers
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

stgraber@dakara:~$ incus exec d13 -- eject /dev/cdrom

stgraber@dakara:~$ incus config show d13
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Debian trixie amd64 (20250731_05:24)
  image.os: Debian
  image.release: trixie
  image.serial: "20250731_05:24"
  image.type: disk-kvm.img
  image.variant: default
  volatile.base_image: 340aab0e87de46062c1363cab4beb7d30d0474adceca5bf450b5162d8c2cc2c5
  volatile.cloud-init.instance-id: 5a79a550-143d-4db0-a223-74191e968ea3
  volatile.eth0.host_name: tap8ca1eb54
  volatile.eth0.hwaddr: 10:66:6a:8e:8e:93
  volatile.last_state.power: RUNNING
  volatile.uuid: af7f680b-7824-47ca-be9a-9189881ade90
  volatile.uuid.generation: af7f680b-7824-47ca-be9a-9189881ade90
  volatile.vm.definition: pc-q35-10.0
  volatile.vm.rtc_adjustment: "0"
  volatile.vm.rtc_offset: "-1"
  volatile.vsock_id: "1524898578"
devices:
  virtio:
    attached: "false"
    pool: default
    source: virtio-drivers
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

Documentation : https://linuxcontainers.org/incus/docs/main/reference/devices_disk/#devices-disk:attached

Configuration du WWN pour les disques des VM¶

Il s’agit d’une fonctionnalité de niche : il est désormais possible de définir le World Wide Name (WWN) des périphériques disque des VM. Cela ne fonctionne que lorsque le disque est attaché au bus virtio-scsi.

Cela peut être utile à certaines applications lorsqu’un LUN ou disque physique est monté dans une VM. La fonctionnalité peut également être utilisée pour tester le multipath dans une VM, en exhibant plusieurs disques avec le même WWN.

stgraber@dakara:~$ incus launch images:debian/13 d13 --vm
Launching d13
stgraber@dakara:~$ incus storage volume create default demo --type=block
Storage volume demo created
stgraber@dakara:~$ incus config device add d13 demo disk pool=default source=demo wwn=0x50014ee20ce3848a
Device demo added to d13
stgraber@dakara:~$ incus exec d13 bash
root@d13:~# ls -lh /dev/disk/by-id/wwn-0x50014ee20ce3848a·
lrwxrwxrwx 1 root root 9 Aug  1 03:49 /dev/disk/by-id/wwn-0x50014ee20ce3848a -> ../../sdb

Documentation : https://linuxcontainers.org/incus/docs/main/reference/devices_disk/#devices-disk:wwn

Adresses IPv6 dynamiques¶

Il s’agit d’une autre fonctionnalité utile dans un nombre très réduit de cas.

Dans les environnements en cluster, il est commun de devoir lancer un certain nombre de services en support du cluster, comme un control plane OVN, des composants Ceph, des outils de supervision…

Pour assurer leur bon fonctionnement, ils doivent pouvoir être contactés depuis tous les serveurs du cluster, tout en étant facilement déplaçables d’un serveur à l’autre, en cas de maintenance ou d’incident. Généralement, cela est assuré par un réseau physique, avec un VLAN routé accessible à tous les serveurs, mais ça n’est pas le cas partout.

Pour les environnements qui ne suivent pas cette architecture, nous proposons un bridge au sein du cluster qui, combiné à notre support VXLAN multicast, donne lieu à un réseau virtuel léger disponible pour tous les serveurs.

Vient ensuite la question de l’adressage. Nous ne pouvons pas faire tourner un serveur DHCPv4 sur ce réseau sans coordination entre les serveurs, mais nous pouvons faire du SLAAC dérivé à partir des adresses MAC.

Pour que cela fonctionne, les serveurs doivent utiliser une adresse MAC différente pour ce bridge, et, plus important encore, utiliser une adresse IPv6 différente (dans le même sous-réseau).

Nous avons ainsi étendu la syntaxe de ipv6.address pour permettre d’y spécifier un sous-réseau seul. Quand c’est le cas, le serveur va générer une adresse MAC unique pour le bridge, puis en dériver une adresse IPv6 (avec EUI64).

Voici le résultat :

root@server01:~# incus network create meshbr0 tunnel.mesh.interface=enp5s0 --target server01
Network meshbr0 pending on member server01
root@server01:~# incus network create meshbr0 tunnel.mesh.interface=enp5s0 --target server02
Network meshbr0 pending on member server02
root@server01:~# incus network create meshbr0 tunnel.mesh.interface=enp5s0 --target server03
Network meshbr0 pending on member server03
root@server01:~# incus network create meshbr0 tunnel.mesh.interface=enp5s0 --target server04
Network meshbr0 pending on member server04
root@server01:~# incus network create meshbr0 ipv4.address=none ipv6.address=fd42:1234:1234:1234::/64 ipv6.nat=false tunnel.mesh.protocol=vxlan
Network meshbr0 created

root@server01:~# incus launch images:debian/13 c1 --network meshbr0
Launching c1
root@server01:~# incus launch images:debian/13 c2 --network meshbr0
Launching c2
root@server01:~# incus launch images:debian/13 c3 --network meshbr0
Launching c3

root@server01:~# incus list
+------+---------+------+------------------------------------------------+-----------+-----------+----------+
| NAME |  STATE  | IPV4 |                      IPV6                      |   TYPE    | SNAPSHOTS | LOCATION |
+------+---------+------+------------------------------------------------+-----------+-----------+----------+
| c1   | RUNNING |      | fd42:1234:1234:1234:1266:6aff:fe60:6aa9 (eth0) | CONTAINER | 0         | server04 |
+------+---------+------+------------------------------------------------+-----------+-----------+----------+
| c2   | RUNNING |      | fd42:1234:1234:1234:1266:6aff:fef8:b9ef (eth0) | CONTAINER | 0         | server04 |
+------+---------+------+------------------------------------------------+-----------+-----------+----------+
| c3   | RUNNING |      | fd42:1234:1234:1234:1266:6aff:fe21:1203 (eth0) | CONTAINER | 0         | server01 |
+------+---------+------+------------------------------------------------+-----------+-----------+----------+
root@server01:~# incus exec c3 bash
root@c3:~# ping6 -n fd42:1234:1234:1234:1266:6aff:fe60:6aa9
PING fd42:1234:1234:1234:1266:6aff:fe60:6aa9 (fd42:1234:1234:1234:1266:6aff:fe60:6aa9) 56 data bytes
64 bytes from fd42:1234:1234:1234:1266:6aff:fe60:6aa9: icmp_seq=1 ttl=64 time=1.38 ms
^C
--- fd42:1234:1234:1234:1266:6aff:fe60:6aa9 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.375/1.375/1.375/0.000 ms

Configuration du mode keepalive dans la CLI¶

L’outil en ligne de commande d’Incus a un mode keepalive depuis un certain moment.
Celui-ci permet de garder une connexion active avec un serveur Incus distant, même après l’arrêt du processus de la CLI, rendant l’exécution des commandes suivantes plus rapide.

Il est désormais possible d’activer ce mode à l’ajout d’un serveur distant en passant l’argument --keepalive, avec le délai souhaité pour le processus en arrière-plan.

stgraber@dakara:~$ incus remote add cloud https://shf.cloud.zabbly.com --keepalive=30
URL: https://sso.zabbly.com/realms/master/device?user_code=WGSI-NFRG
Code: WGSI-NFRG

stgraber@dakara:~$ incus list cloud: --project demo
+-----------+---------+-------------------------+---------------------------------------------------+-----------------+-----------+----------+
|   NAME    |  STATE  |          IPV4           |                       IPV6                        |      TYPE       | SNAPSHOTS | LOCATION |
+-----------+---------+-------------------------+---------------------------------------------------+-----------------+-----------+----------+
| haproxy01 | RUNNING | 45.45.148.243 (eth0)    | 2602:fc62:b:8006:216:3eff:fe27:a8f4 (eth0)        | CONTAINER       | 0         | delmak   |
|           |         | 10.22.45.7 (eth0)       | 2602:fc62:b:8006:1::1 (eth0)                      |                 |           |          |
+-----------+---------+-------------------------+---------------------------------------------------+-----------------+-----------+----------+
| ic-test   | RUNNING | 10.47.238.2 (eth0)      | fd42:4a11:5600:6807:216:3eff:feb5:2c79 (eth0)     | CONTAINER       | 0         | chulak   |
+-----------+---------+-------------------------+---------------------------------------------------+-----------------+-----------+----------+
| server01  | RUNNING | 10.46.12.1 (br-managed) | fd42:ea64:f916:62b0::1 (br-managed)               | VIRTUAL-MACHINE | 0         | chulak   |
|           |         | 10.22.45.3 (enp5s0)     | fd42:1234:1234:1234:1266:6aff:fe6b:48d2 (meshbr0) |                 |           |          |
|           |         |                         | 2602:fc62:b:8006:216:3eff:fe1a:ed0d (enp5s0)      |                 |           |          |
+-----------+---------+-------------------------+---------------------------------------------------+-----------------+-----------+----------+
| server02  | RUNNING | 10.46.12.1 (br-managed) | fd42:ea64:f916:62b0::1 (br-managed)               | VIRTUAL-MACHINE | 0         | chulak   |
|           |         | 10.22.45.4 (enp5s0)     | fd42:1234:1234:1234:1266:6aff:fea1:6d39 (meshbr0) |                 |           |          |
|           |         |                         | 2602:fc62:b:8006:216:3eff:fe56:5276 (enp5s0)      |                 |           |          |
+-----------+---------+-------------------------+---------------------------------------------------+-----------------+-----------+----------+
| server03  | RUNNING | 10.46.12.1 (br-managed) | fd42:ea64:f916:62b0::1 (br-managed)               | VIRTUAL-MACHINE | 0         | chulak   |
|           |         | 10.22.45.5 (enp5s0)     | fd42:1234:1234:1234:1266:6aff:fe14:8b09 (meshbr0) |                 |           |          |
|           |         |                         | 2602:fc62:b:8006:216:3eff:fec6:eaa8 (enp5s0)      |                 |           |          |
+-----------+---------+-------------------------+---------------------------------------------------+-----------------+-----------+----------+
| server04  | RUNNING | 10.46.12.1 (br-managed) | fd42:ea64:f916:62b0::1 (br-managed)               | VIRTUAL-MACHINE | 0         | chulak   |
|           |         | 10.22.45.6 (enp5s0)     | fd42:1234:1234:1234:1266:6aff:fef0:2a72 (meshbr0) |                 |           |          |
|           |         |                         | 2602:fc62:b:8006:216:3eff:fea3:6d (enp5s0)        |                 |           |          |
+-----------+---------+-------------------------+---------------------------------------------------+-----------------+-----------+----------+

stgraber@dakara:~$ ps aux | grep remote.*proxy
stgraber 1411159  0.1  0.0 6258948 26704 ?       Ssl  00:19   0:00 incus remote proxy cloud /home/stgraber/.config/incus/keepalive/cloud.socket --timeout=30

Support de Markdown comme format de sortie de la CLI¶

Il est à présent possible de formatter le retour des commandes d’Incus en Markdown, simplifiant leur inclusion dans des documents ou encore sur notre forum.

stgraber@dakara:~$ incus list --format=markdown
|    NAME     |  STATE  |          IPV4          |                     IPV6                     |      TYPE       | SNAPSHOTS |
|:-----------:|:-------:|:----------------------:|:--------------------------------------------:|:---------------:|:---------:|
|     d13     | RUNNING | 172.17.250.33 (enp5s0) | 2602:fc62:c:250:1266:6aff:fe8e:8e93 (enp5s0) | VIRTUAL-MACHINE |     0     |
|  incus-os   | RUNNING | 10.87.35.1 (incusbr0)  |      fd42:6060:5090:8d31::1 (incusbr0)       | VIRTUAL-MACHINE |     0     |
|             |         |                        | 2602:fc62:c:250:1266:6aff:fe91:c98 (enp5s0)  |                 |           |
| kernel-test | STOPPED |                        |                                              | VIRTUAL-MACHINE |     0     |
|   win2025   | STOPPED |                        |                                              | VIRTUAL-MACHINE |     0     |

Le rendu est le suivant :

Davantage de filtrage côté serveur¶

Dans cette version, nous achevons le support dans la CLI du filtrage côté serveur des objets de l’API.

Les deux commandes qui supportent à présent le filtrage sont :

• incus cluster list
• incus storage list

Utilisation de netlink pour la configuration réseau¶

Il ne s’agit pas d’une nouvelle fonctionnalité en soi, mais cela représente toutefois un changement conséquent.
Avec cette nouvelle version, nous avons remplacé nos appels manuels à iproute2 (ip, tc…) par des interactions directes avec le noyau Linux au travers de son API netlink.

Cela enlève un certain nombre de surcouches, et nous permet de ne plus avoir à nous soucier des versions des outils utilisés, mais ce genre de grands changements vient avec un risque de régression.

Pour cette raison, nous avons migré immédiatement après la version 6.14, nous laissant un mois complet pour identifier et corriger ces régressions. Nous en avons identifié un certain nombre, que nous avons résolues, mais il est possible que nos tests en aient manqué.

Si vous repérez une quelconque régression ou un changement de comportement sur les interfaces réseau ou le routage, merci de nous le faire savoir pour que nous analysions le problème.

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.15.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.14 est maintenant disponible¶

28 juin 2025

Introduction¶

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

C’est une version avec de plus modestes apports : quelques corrections de bugs et améliorations de performances, concluant une partie du travail mené avec les étudiants de l’Université du Texas, et quelques nouvelles fonctionnalités.

Elle corrige également quelques vulnérabilités affectant les personnes utilisant des ACL sur des réseaux bridge avec un pare-feu nftables.

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

Correctifs de sécurité¶

Cette nouvelle version corrige deux vulnérabilités rapportées par Olivier BAL-PETRE, de l’ANSSI (agence française de sécurité des systèmes d'information).

Les deux vulnérabilités étaient liées à l’utilisation par Incus d’ACL réseau sur des bridges locaux utilisant un pare-feu nftables, en combinaison avec certaines de nos fonctionnalités d’isolation réseau.

Un changement récent dans la logique des ACL dans Incus 6.12 permettait d’outrepasser certains mécanismes d’isolation et d’autoriser l’utilisateur root sur une instance à causer une attaque par déni de service ou à se faire passer pour l’hôte et potentiellement intercepter du trafic d’instances du même réseau.

• CVE-2025-52890 (Incus creates nftables rules that partially bypass security options)
• CVE-2025-52889 (Incus Allocation of Resources Without Limits allows firewall rule bypass on managed bridge networks)

Comme mentionné, les versions concernées sont Incus 6.12 et Incus 6.13. Ces deux versions mensuelles d’Incus ne sont à présent plus supportées du fait de la sortie d’Incus 6.14.
La dernière version LTS n’est pas affectée par ces vulnérabilités.

Nouvelles fonctionnalités¶

Téléversement de sauvegardes d’instances et de volumes via S3¶

Les sauvegardes d’instances et de volumes peuvent désormais être automatiquement téléversées dans un bucket S3. Cette fonctionnalité est pour l’instant uniquement disponible au travers de l’API, pour une éventuelle utilisation par des systèmes de sauvegarde.

Incus générera comme d’habitude un fichier de sauvegarde, puis le téléversera vers le bucket cible avant de supprimer sa copie locale.

stgraber@dakara:~$ incus launch images:alpine/edge a1
Launching a1
stgraber@dakara:~$ incus query -X POST /1.0/instances/a1/backups -d '{"optimized_storage": true, "target": {"protocol": "s3", "url": "https://storage.googleapis.com", "bucket_name": "incus_backups", "path": "my-backup.tar.gz", "access_key": "ACCESS-KEY", "secret_key": "SECRET-KEY"}}' --wait
{
    "class": "task",
    "created_at": "2025-06-28T13:46:21.781378949-04:00",
    "description": "Backing up instance",
    "err": "",
    "id": "89936d87-25b3-44d2-930e-92b579cc2ee0",
    "location": "none",
    "may_cancel": false,
    "metadata": null,
    "resources": {
        "backups": [
            "/1.0/instances/a1/backups/backup0"
        ],
        "instances": [
            "/1.0/instances/a1"
        ]
    },
    "status": "Success",
    "status_code": 200,
    "updated_at": "2025-06-28T13:46:21.781378949-04:00"
}

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

Personnalisation de l’expiration des instantanés à leur création¶

Une nouvelle option --expiry a été ajoutée aux commandes incus snapshot create et incus storage volume snapshot create. Celle-ci permet de modifier la date d’expiration d’un instantané à sa création, changeant la valeur par défaut du serveur.

stgraber@dakara:~$ incus snapshot create a1 foo --expiry=2d
stgraber@dakara:~$ incus snapshot list a1
+------+----------------------+----------------------+----------+
| NAME |       TAKEN AT       |      EXPIRES AT      | STATEFUL |
+------+----------------------+----------------------+----------+
| foo  | 2025/06/28 13:50 EDT | 2025/06/30 13:50 EDT | NO       |
+------+----------------------+----------------------+----------+

Modification du délai d’expiration par défaut pour les instantanés créés manuellement¶

Le délai d’expiration par défaut peut maintenant être modifié par l’intermédiaire de la clef de configuration snapshots.expiry.manual. Lorsqu’elle n’est pas définie, Incus utilise la valeur snapshots.expiry, qui est également utilisée pour les instantanés créés automatiquement.

stgraber@dakara:~$ incus config set a1 snapshots.expiry=7d
stgraber@dakara:~$ incus snapshot create a1 first
stgraber@dakara:~$ incus config set a1 snapshots.expiry.manual=2d
stgraber@dakara:~$ incus snapshot create a1 second
stgraber@dakara:~$ incus snapshot list a1
+--------+----------------------+----------------------+----------+
|  NAME  |       TAKEN AT       |      EXPIRES AT      | STATEFUL |
+--------+----------------------+----------------------+----------+
| first  | 2025/06/28 13:53 EDT | 2025/07/05 13:53 EDT | NO       |
+--------+----------------------+----------------------+----------+
| second | 2025/06/28 13:54 EDT | 2025/06/30 13:54 EDT | NO       |
+--------+----------------------+----------------------+----------+

Ajustements dans la migration à chaud et information d’avancement¶

Pour réduire le temps de migration pour les VM qui modifient activement leur mémoire, nous avons effectué quelques ajustements dans la logique de transfert de la mémoire.

Incus va à présent limiter plus agressivement le CPU des VM en cours de migration, en commençant par une limitation à 50 % de sa capacité après la première tentative de migration, puis en la limitant davantage si beaucoup de changements ont eu lieu en RAM.

Enfin, Incus va à présent fournir des informations sur l’avancement de la migration.

Information sur la taille des adresses CPU dans l’API des ressources¶

D’un CPU et d’une plateforme à l’autre, les adresses physiques et virtuelles peuvent avoir des tailles différentes.

Cela contraint la quantité de mémoire maximale disponible pour une machine virtuelle, que ce soit au démarrage ou après un hotplug.

Pour cette raison, Incus a besoin de surveiller ces valeurs pour ajuster la quantité maximale de mémoire hotpluggable dans les VM.

stgraber@castiana:~$ incus query /1.0/resources | jq .cpu.sockets[0].address_sizes
{
  "physical_bits": 48,
  "virtual_bits": 48
}

Transition des traitements en base de données vers notre générateur de code¶

Nous avons procédé à la transition d’un certain nombre d’objets réseau vers notre générateur de code pour les traitements en base de données.

Dans cette version, les deux objets suivants ont été convertis :

• Redirections réseau
• Peers réseau

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.14.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.13 est maintenant disponible¶

30 mai 2025

Introduction¶

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

Cette version apporte BEAUCOUP de nouvelles fonctionnalités de toutes tailles et pour tous les cas d’utilisation, donc tout le monde devrait être servi !

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

Nouvelles fonctionnalités¶

Agent pour les VM Windows¶

La logique de l’agent Incus pour les VM a été refactorisée pour que celui-ci soit construit pour des systèmes d’exploitation autres que Linux, et une première implémentation pour Windows a été réalisée.

Il s’agit encore d’un travail préliminaire, puisque Windows ne possède pas de driver VirtIO signé pour vsock, qu’Incus utilise normalement pour communiquer avec son agent.

Cependant, le protocole que nous utilisons par-dessus vsock est HTTPS, donc nous nous en sommes contentés pour nous connecter (via le réseau donc) à l’agent Windows. Cela ne peut fonctionner que si Incus connaît l’adresse IP de la VM, et que celle-ci est directement joignable depuis l’hôte. Nous avons pour espoir de remplacer cette solution par une connexion vsock native dans le futur.

Cet agent permet de lancer des commandes avec incus exec, d’obtenir les détails de l’OS avec incus info et de transférer des fichiers avec incus file.

Pour que l’agent fonctionne, il faut attacher un disque avec source=agent:config à la VM Windows, qui se présente à l’OS comme un CD-ROM content l’agent Windows (s’il a été packagé dans la distribution de l’hôte) ainsi que les fichiers de configuration nécessaires.

À partir de là, vous pouvez démarrer l’agent manuellement ou le configurer comme un service système.

Nous aimerions des retours de personnes ayant de l’expérience dans les systèmes Windows pour améliorer l’utilisabilité de l’agent, par exemple en fournissant un script d’installation dans le CD-ROM, ou encore en y incluant les fonctionnalités qui manquent par rapport à l’agent Linux.

Cet effort de plusieurs mois a été rendu possible grâce au soutien financier du Sovereign Tech Fund.

Améliorations dans incus-migrate¶

Un certain nombre d’améliorations ont été apportées à notre outil incus-migrate.

Pour rappel, cet outil peut être lancé sur un serveur distant afin de le convertir en conteneur ou VM Incus, ou de convertir des conteneurs ou VM qu’il virtualise en instances importables dans Incus.

Avec cette nouvelle version, incus-migrate supporte à présent :

• Le téléversement d’arbres de fichiers ou d’images disques comme volumes personnalisés
• L’import de disques additionnels ou de systèmes de fichiers lors de la création d’une nouvelle instance
• L’import d’une image OVA comme nouvelle instance
• La sélection d’un serveur ou d’un groupe de serveurs spécifique lorsqu’Incus est clusterisé

Des binaires statiques de incus-migrate sont disponibles sur GitHub, utiles pour procéder à la conversion d’un système qui n’utilise pas déjà Incus.

Accès aux volumes personnalisés en SFTP¶

Nous cherchons progressivement à ce que les volumes personnalisés (de type système de fichiers) supportent une API similaire à celle que nous avons déjà pour les fichiers des instances.

Nous avons fait un premier pas dans ce sens : Incus supporte désormais les opérations en SFTP sur ces volumes, avec la commande incus storage volume file mount. Les autres APIs et commandes devraient débarquer dans Incus 6.14.

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

Configuration des adresses IP externes des instances sur les réseaux OVN¶

Deux nouvelles clefs de configuration pour les cartes réseau des instances ont été ajoutées :

• ipv4.address.external
• ipv6.address.external

Ces clefs peuvent être utilisées pour configurer quelle adresse IP une instance doit utiliser pour le trafic sortant initié par celle-ci. Il s’agit typiquement de l’adresse externe du réseau (par défaut) ou d’une adresse de forward qui pointe sur l’instance.

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

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

Possibilité de fixer l’adresse MAC de la gateway sur les réseaux OVN¶

OVN gère une table d’association entre les adresses IP et les adresses MAC (équivalente aux tables ARP et NDP). Cette table est peuplée la première fois qu’OVN a besoin d’interagir avec une adresse donnée.

Ce n’est pas toujours idéal, dans la mesure où les réseaux utilisant VRRP ou d’autres mécanismes de MAC virtuelles peuvent avoir besoin de préconfigurer une adresse MAC donnée pour la gateway, et enregistrer l’information dans OVN.

Deux nouvelles clefs de configuration rendent cela possible sur les uplinks OVN de type physical :

• ipv4.gateway.hwaddr
• ipv6.gateway.hwaddr

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

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

Gestion de l’horloge dans les machines virtuelles¶

Incus définit désormais automatiquement l’option invtsc de QEMU sur les machines virtuelles qui n’ont pas pour vocation à être migrées.

De plus, Incus écoute à présent les événements RTC provenant de QEMU afin de rendre persistantes les horloges RTC des VM. Cela permet de mieux gérer les VM Windows ainsi que les autres VM qui n’utilisent pas d’horloge matérielle UTC.

Nouvelles commandes get-client-certificate et get-client-token¶

L’outil en ligne de commande possède deux nouvelles commandes, incus remote get-client-certificate et incus remote get-client-token, permettant de simplifier l’extraction des certificats clients et l’émission de JWT à partir d’un certificat client depuis des scripts externes.

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

Support de DHCPv6 pour les conteneurs OCI¶

Le client DHCP intégré utilisé pour les conteneurs OCI est maintenant capable de faire du DHCPv6 stateful et stateless.

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

Configuration des tables réseau de l’hôte pour les cartes réseau routées¶

Incus permettait de contrôler dans quelle table de routage injecter les routes pour les cartes réseau de type routed, mais cela manquait de flexibilité.

Désormais, nous avons de nouvelles clefs de configuration :

• ipv4.host_tables
• ipv6.host_tables

Celles-ci prennent une liste de tables, séparées par des virgules, dans lesquelles injecter les routes.

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

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

Support de la publication d’images scindées¶

Jusqu’à présent, lancer incus publish générait des images unifiées, à savoir un seul fichier, souvent un tarball compressé, qui contenait à la fois le disque racine et la configuration Incus.

Désormais, nous supportons la génération d’images scindées, composées de deux fichiers, l’un pour les métadonnées Incus et l’autres pour les données du disque racine.

Dans l’outil en ligne de commande, il suffit de passer l’option --format=split à incus publish.

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

Preseed de certificats¶

Les preseeds des serveurs Incus peuvent désormais inclure des certificats.

Par exemple :

certificates:
  - type: client
    name: my-client
    certificate: |-
      PEM ENCODED CERTIFICATE

Cette fonctionnalité est particulièrement utile lors du provisionnement automatique de systèmes comme Incus OS.

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

Configuration du formattage des listes¶

Le fichier de configuration de l’outil en ligne de commande d’Incus (habituellement ~/.config/incus/config.yml) peut maintenant être utilisé pour définir un format d’affichage pour les listes.

Par exemple :

defaults:
  list_format: compact

Cet exemple est équivalent à passer --format=compact à toutes les commandes list.

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

Ajout d’alias pour les commandes de création et de suppression¶

L’invite de commande Incus a été conçue de telle sorte que :

• Un objet portant un état a besoin d’être créé (create) et supprimé (delete)
• Un objet ou une relation sans état a besoin d’être ajouté (add) et enlevé (remove)

Cette distinction a été faite pour signaler le risque associé à chaque action, mais peut également donner une impression de manque de cohérence, rendant ainsi plus complexe la création de scripts autour d’Incus.

Pour résoudre ce problème, nous avons ajouté un certain nombre d’alias dans l’outil en ligne de commande afin de trouver plus rapidement la commande voulue.

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

Conversion des appels SQL codés en dur vers notre générateur de code¶

La base de code d’Incus inclut un générateur de code pour les appels à la base de données.
Ce générateur est utile pour garantir la cohérence du comportement et éviter un certain nombre d’erreurs qui peuvent être commises en écrivant des requêtes à la main.

Bien qu’il soit de fait requis que toutes les nouvelles tables de la base utilisent le générateur, nous avons toujours un certain nombre d’objets qui ne l’utilisent pas.

Avec cette nouvelle version, nous avons terminé la migration des objets suivants :

• ACL réseau
• Load-balancers réseau
• Zones réseau

Bien que tous nos tests soient au vert, ce genre de refonte présente un certain risque d’introduction de régressions. Si vous notez le moindre changement de comportement avec ces objets dans Incus 6.13, merci d’ouvrir une issue pour que nous puissions investiguer.

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

Filtrage côté serveur¶

Cette nouvelle version étend davantage les fonctionnalités de filtrage côté serveur.

Le filtrage est maintenant supporté pour :

• incus network list
• incus storage bucket list
• incus project list
• incus config trust list

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

Documentation générée à partir du code¶

Nous avons également continué notre projet de génération automatique de documentation pour les clefs de configuration. Dans cette version, nous avons à présent de la documentation générée pour :

• Les périphériques PCI
• Les réseaux OVN
• Les réseaux physiques
• Les réseaux SR-IOV
• Les réseaux macvlan

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

Intégration des métriques d’Incus OS dans l’API d’export des métriques Incus¶

Lorsqu’Incus est lancé depuis Incus OS, les métriques de l’hôte (extraites avec node-exporter) sont désormais automatiquement incluses dans l’API d’export de métriques d’Incus.

Ce choix a été fait car Incus OS essaie de limiter au maximum le nombre de ports ouverts, et d’imposer au trafic d’être authentifié et autorisé au travers d’une pile logicielle unique (Incus lui-même).

Avis pour les packagers¶

Nous n’utilisons plus la commande externe umoci et lui avons préféré le paquet Go équivalent.

Pour bénéficier du support du nouvel agent Windows, celui-ci doit également être compilé pour Windows, et rendu disponible à Incus en complément de l’agent Linux.

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.13.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.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

Anciennes nouvelles¶

• 28 mars 2025
• 28 févr. 2025
• 24 janv. 2025
• 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