Actualités¶

Incus 6.5 est maintenant disponible¶

6 sept. 2024

Introduction¶

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

Cette version met en particulier l’accent sur les performances. Les appels internes coûteux en ressources comme la résolution d’un grand nombre de profils et de périphériques ont été optimisés de façon significative, avec des gains de performance de l’ordre de 20 à 30 ×. De même, la gestion des systèmes comportant des milliers d’instances par serveur a également été grandement améliorée, réduisant les vérifications au démarrage de plusieurs dizaines de minutes à quelques dizaines de secondes.

Mais cette version ne fait pas que résoudre des bugs ; Incus 6.5 introduit également quelques nouvelles fonctionnalités et améliorations. Qu’il s’agisse d’augmenter la cohérence de notre CLI, de simplifier l’exécution d’opérations de bas niveau sur les machines virtuelles, d’améliorer la vie des utilisateurs de conteneurs d’application, ou de proposer de nouvelles fonctionnalités aux utilisateurs d’OVN, cette version devrait avoir quelque chose à proposer à tout le monde.

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

Nouvelles fonctionnalités¶

Redémarrage automatique d’instances¶

Depuis que nous avons ajouté le support des conteneurs d’application dans Incus, une demande récurrente était de pouvoir redémarrer automatiquement les instances lorsqu’elles se terminent, rendant plus facile la gestion des application qui plantent ou se rechargent.

Ce comportement est maintenant contrôlé par une nouvelle clef de configuration, boot.autorestart, qui, lorsqu’elle est définie à true, permet à Incus de tenter un redémarrage de l’instance jusqu’à 10 fois sur une période d’une minute.

Les arrêts des instances demandés par les utilisateurs ne déclenchent pas la logique de redémarrage automatique.

stgraber@castiana:~$ incus launch docker:nginx nginx -c boot.autorestart=true
Launching nginx
stgraber@castiana:~$ incus info nginx | grep PID
PID: 178789
stgraber@castiana:~$ sudo kill -9 178789
stgraber@castiana:~$ incus list nginx
+-------+---------+----------------------+-----------------------------------------------+-----------------+-----------+
| NAME  |  STATE  |         IPV4         |                     IPV6                      |      TYPE       | SNAPSHOTS |
+-------+---------+----------------------+-----------------------------------------------+-----------------+-----------+
| nginx | RUNNING | 10.178.240.76 (eth0) | fd42:8384:a6f8:63a0:216:3eff:fef4:5a27 (eth0) | CONTAINER (APP) | 0         |
+-------+---------+----------------------+-----------------------------------------------+-----------------+-----------+
stgraber@castiana:~$

Documentation : https://linuxcontainers.org/incus/docs/main/reference/instance_options/#boot-related-options

Sélection des colonnes dans toutes les commandes de listage¶

Sur les dernières versions, nous avons travaillé à l’amélioration de la cohérence des commandes de la CLI incus. Nous avons tout d’abord ajouté le support de --format à toutes les commandes list, et dans cette nouvelle version, toutes les commandes list acceptent désormais --columns.

Cela permet de personnaliser facilement le résultat de la commande incus et de la scripter, en combinant à la fois --format=csv et --columns= pour sélectionner les colonnes pertinentes.

stgraber@castiana:~$ incus snapshot list v1 --columns=nT --format=csv
snap0,2024/09/06 15:04 EDT
snap1,2024/09/06 15:04 EDT

Hooks et scriptlet QMP¶

Incus s’appuie actuellement sur QEMU pour faire fonctionner ses machines virtuelles.

La manière dont Incus interagit avec QEMU peut être parfois assez complexe, car cela peut être effectué au travers de trois mécanismes différents :

• La ligne de commande de QEMU
• Le fichier de configuration de QEMU
• Le protocole QMP (QEMU Machine Protocol)

Nous essayons généralement d’éviter de polluer la ligne de commande autant que possible, c’est pourquoi elle est réduite au minimum, mais nous permettons de lui passer des paramètres supplémentaires avec raw.qemu.

Notre préférence pour tout périphérique qui n’a pas besoin d’être mis à jour dynamiquement ou n’a pas besoin d’être débranché et rebranché à chaud est l’utilisation du fichier de configuration de QEMU. Il peut être facilement généré à l’aide de templates, et peut aisément être testé. L’option de configuration raw.qemu.conf peut être utilisée pour étendre ou remplacer le contenu de ce fichier de configuration.

Enfin, nous avons QMP, que nous utilisons pour tout ce qui est branchable à chaud, à savoir tous les disques, interfaces réseau, et périphériques USB et PCI. L’équipe en charge de QEMU essaie peu à peu de déprécier l’utilisation du fichier de configuration, nous incitant à utiliser de plus en plus QMP pour la configuration des VM.

Le principal problème avec QMP jusqu’à présent est que, contrairement à la ligne de commande et au fichier de configuration de QEMU, le protocole est très opaque. Il n’est pas possible de voir facilement ce qui a été configuré, et comme tous les objets ont été configurés après le démarrage de QEMU, il n’était pas possible de remplacer ou reconfigurer ceux-ci avec les mécanismes existants.

Mais les choses sont désormais différentes grâce à ces nouvelles options de configuration :

• raw.qemu.qmp.early
• raw.qemu.qmp.pre-start
• raw.qemu.qmp.post-start
• raw.qemu.scriptlet

Les trois premières prennent une liste de commandes QMP encodée en JSON. Les commandes QMP sont en principe déjà encodées en JSON, donc leur ajout à la configuration des instances est très simple. Les commandes sont lancées dans l’ordre pour chacune des étapes suivantes.

early correspond au moment précédent toute exécution de commandes QMP de la part d’Incus, pre-start correspond au moment où Incus a ajouté tous ses périphériques en QMP, avant le lancement de la VM, et post-start correspond au moment où la VM vient d’être lancée par QEMU.

raw.qemu.scriptlet est une option encore plus flexible, car elle prend un scriptlet (dans une syntaxe proche de Python) qui doit définir une fonction qemu_hook à laquelle un argument stage (correspondant à l’une des étapes précédentes, early, pre-start et post-start) est passé. La différence par rapport aux options raw.qemu.qmp est que le scriptlet peut gérer les réponses aux commandes QMP et avoir une logique pour y réagir.

Cela signifie que ce scriptlet QEMU peut appeler la fonction run_qmp, lui passer une commande QMP, lire sa valeur de retour, et envoyer plus de commandes si besoin, permettant la reconfiguration dynamique de la VM.

Notez qu’il s’agit d’un mécanisme de très bas niveau que seuls les utilisateurs experts sont censés utiliser, dans des cas très spécifiques. Comme pour toutes les clefs de configuration raw, son utilisation n’est pas supportée par l’équipe d’Incus, et elle doit être désactivée pour tout projet qui n’est pas considéré comme fiable.

Support du redimensionnement des disques à chaud pour les machines virtuelles¶

Il est désormais possible de redimensionner le disque racine ou tout autre disque attaché à une VM, et d’informer la VM du changement. Le système d’exploitation met alors à jour la taille du disque et permet à l’utilisateur de profiter de cet espace additionnel sans avoir à redémarrer la VM.

stgraber@castiana:~$ incus exec v1 bash
root@v1:~# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   10G  0 disk
├─sda1   8:1    0  100M  0 part /boot/efi
└─sda2   8:2    0  9.9G  0 part /
root@v1:~#
exit

stgraber@castiana:~$ incus config device override v1 root size=20GiB
Device root overridden for v1

stgraber@castiana:~$ incus exec v1 bash
root@v1:~# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   20G  0 disk
├─sda1   8:1    0  100M  0 part /boot/efi
└─sda2   8:2    0  9.9G  0 part /
root@v1:~#

Hotplug des périphériques PCI¶

L’ajout et la suppression de périphériques PCI sur une VM peuvent désormais être effectués à chaud.
La fonctionnalité est similaire à ce qui était fait pour les cartes réseau, les GPU et les disques.

Surveillance de l’état des load-balancers OVN¶

Le support d’Incus pour les load-balancers OVN a jusqu’à présent été très basique, se limitant essentiellement à de l’équilibrage de trafic simple sans monitoring.

Mais cela est en train de changer, avec la prise en charge initiale de la surveillance de l’état de santé des load-balancers OVN.
Ceci est configuré avec les clefs de configuration suivantes sur le load-balancer :

• healthcheck => Active la surveillance de l’état de santé
• healthcheck.failure_count => Nombre de tentatives échouées avant de considérer le backend comme défaillant
• healthcheck.interval => Intervalle de vérification des backends (en secondes)
• healthcheck.success_count => Nombre de tentatives réussies avant de considérer le backend comme fonctionnel
• healthcheck.timeout => Temps d’attente d’une réponse avant de considérer une requête comme échouée

Seul healthcheck est requis ; toutes les autres clefs ont des valeurs par défaut raisonnables.

root@server01:~# incus launch images:ubuntu/24.04 c1
Launching c1
root@server01:~# incus exec c1 -- apt-get install --yes nginx
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  nginx-common
Suggested packages:
  fcgiwrap nginx-doc ssl-cert
The following NEW packages will be installed:
  nginx nginx-common
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 552 kB of archives.
After this operation, 1596 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu noble/main amd64 nginx-common all 1.24.0-2ubuntu7 [31.2 kB]
Get:2 http://archive.ubuntu.com/ubuntu noble/main amd64 nginx amd64 1.24.0-2ubuntu7 [521 kB]
Fetched 552 kB in 1s (619 kB/s)
Preconfiguring packages ...
Selecting previously unselected package nginx-common.
(Reading database ... 16176 files and directories currently installed.)
Preparing to unpack .../nginx-common_1.24.0-2ubuntu7_all.deb ...
Unpacking nginx-common (1.24.0-2ubuntu7) ...
Selecting previously unselected package nginx.
Preparing to unpack .../nginx_1.24.0-2ubuntu7_amd64.deb ...
Unpacking nginx (1.24.0-2ubuntu7) ...
Setting up nginx (1.24.0-2ubuntu7) ...
Setting up nginx-common (1.24.0-2ubuntu7) ...
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.
root@server01:~# incus launch images:ubuntu/24.04 c2
Launching c2
root@server01:~# incus list
+------+---------+--------------------+-----------------------------------------------+-----------+-----------+----------+
| NAME |  STATE  |        IPV4        |                     IPV6                      |   TYPE    | SNAPSHOTS | LOCATION |
+------+---------+--------------------+-----------------------------------------------+-----------+-----------+----------+
| c1   | RUNNING | 10.104.61.2 (eth0) | fd42:73ae:9013:c530:216:3eff:feff:ddf2 (eth0) | CONTAINER | 0         | server01 |
+------+---------+--------------------+-----------------------------------------------+-----------+-----------+----------+
| c2   | RUNNING | 10.104.61.3 (eth0) | fd42:73ae:9013:c530:216:3eff:fec4:611 (eth0)  | CONTAINER | 0         | server02 |
+------+---------+--------------------+-----------------------------------------------+-----------+-----------+----------+

root@server01:~# incus network load-balancer create default 172.31.254.50
Network load balancer 172.31.254.50 created
root@server01:~# incus network load-balancer backend add default 172.31.254.50 c1 10.104.61.2
root@server01:~# incus network load-balancer backend add default 172.31.254.50 c2 10.104.61.3
root@server01:~# incus network load-balancer port add default 172.31.254.50 tcp 80 c1,c2

root@server01:~# incus launch images:ubuntu/24.04 t1
Launching t1
root@server01:~# incus exec t1 -- nc -v 172.31.254.50 80
nc: connect to 172.31.254.50 port 80 (tcp) failed: Connection refused
root@server01:~# incus exec t1 -- nc -v 172.31.254.50 80
nc: connect to 172.31.254.50 port 80 (tcp) failed: Connection refused
root@server01:~# incus exec t1 -- nc -v 172.31.254.50 80
Connection to 172.31.254.50 80 port [tcp/http] succeeded!

root@server01:~# incus network load-balancer set default 172.31.254.50 healthcheck=true

root@server01:~# incus exec t1 -- nc -v 172.31.254.50 80
Connection to 172.31.254.50 80 port [tcp/http] succeeded!
^Croot@server01:~# incus exec t1 -- nc -v 172.31.254.50 80
Connection to 172.31.254.50 80 port [tcp/http] succeeded!
^Croot@server01:~# incus exec t1 -- nc -v 172.31.254.50 80
Connection to 172.31.254.50 80 port [tcp/http] succeeded!
^Croot@server01:~# incus exec t1 -- nc -v 172.31.254.50 80
Connection to 172.31.254.50 80 port [tcp/http] succeeded!
^Croot@server01:~# incus exec t1 -- nc -v 172.31.254.50 80
Connection to 172.31.254.50 80 port [tcp/http] succeeded!

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

Support d’ECMP pour les interconnexions OVN¶

Le support des interconnexions OVN par les intégrations réseau a été étendu de plusieurs manières différentes :

• L’option de configuration ovn.transit.pattern accepte désormais une nouvelle variable peerName
• Il est maintenant possible d’avoir plusieurs peers sur un réseau ciblant la même intégration réseau
• L’allocation d’IP sur le switch de transit est désormais enregistrée directement dans la base de données OVN, plutôt que de s’appuyer sur des sous-réseaux aléatoires

Enfin, il est maintenant possible de changer la valeur par défaut core.transit.pattern pour inclure peerName dans le template, afin d’ajouter plusieurs peers à un réseau pointant tous sur la même interconnexion.

En interne, cela se traduit par la création de plusieurs switchs de transit et, tant que les noms des peers correspondent sur tous les systèmes, le trafic sera équilibré entre ces switchs en ECMP.

Cela permet d’équilibrer très efficacement la charge du trafic d’interconnexion.

root@chulak:~# incus list ic
+---------+---------+--------------------+-----------------------------------------------+-----------+-----------+----------+
|  NAME   |  STATE  |        IPV4        |                     IPV6                      |   TYPE    | SNAPSHOTS | LOCATION |
+---------+---------+--------------------+-----------------------------------------------+-----------+-----------+----------+
| ic-test | RUNNING | 10.47.238.2 (eth0) | fd42:4a11:5600:6807:216:3eff:feb5:2c79 (eth0) | CONTAINER | 0         | chulak   |
+---------+---------+--------------------+-----------------------------------------------+-----------+-----------+----------+
root@chulak:~# incus exec ic-test bash
root@ic-test:~# ping 10.170.69.2
PING 10.170.69.2 (10.170.69.2) 56(84) bytes of data.
From 45.45.148.162 icmp_seq=1 Destination Net Unreachable
--- 10.170.69.2 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
root@ic-test:~#

root@chulak:~# incus network peer create ovn-ic-test peer1 dcmtl --type=remote
Network peer peer1 created
root@chulak:~# incus network peer create ovn-ic-test peer2 dcmtl --type=remote
Network peer peer2 created
root@chulak:~# incus network peer create ovn-ic-test peer3 dcmtl --type=remote
Network peer peer3 created
root@chulak:~# incus network peer create ovn-ic-test peer4 dcmtl --type=remote
Network peer peer4 created

root@chulak:~# incus exec ic-test bash
root@ic-test:~# ping 10.170.69.2
PING 10.170.69.2 (10.170.69.2) 56(84) bytes of data.
64 bytes from 10.170.69.2: icmp_seq=1 ttl=62 time=11.8 ms
64 bytes from 10.170.69.2: icmp_seq=2 ttl=62 time=6.01 ms
--- 10.170.69.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 6.012/8.930/11.848/2.918 ms

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

Mode promiscuous pour les cartes réseau OVN¶

Une nouvelle clef de configuration security.promiscuous est maintenant disponible pour les cartes réseau OVN.

Lorsqu’elle est activée, tout le trafic OVN dont la destination est une adresse MAC inconnue est envoyé vers la carte réseau OVN.

L’utilisation principale de cette fonctionnalité est dans les environnements imbriqués, dans lesquels vous pouvez vouloir des conteneurs ou des VM imbriqués directement connectés au réseau OVN parent, sans port dédié.
Ce cas d’usage relève du développement ou du test, car le mode promiscuous provoque beaucoup de trafic inutile sur la carte réseau.

root@server01:~# incus launch images:ubuntu/24.04 t1
Launching t1
root@server01:~# incus exec t1 bash
root@t1:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
48: eth0@if49: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1422 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:16:3e:f3:d4:3e brd ff:ff:ff:ff:ff:ff link-netnsid 0
root@t1:~# ip link set eth0 address 00:16:3e:f3:d4:30
root@t1:~# ip -4 a add dev eth0 10.104.61.100/24
root@t1:~# ping 10.104.61.1
PING 10.104.61.1 (10.104.61.1) 56(84) bytes of data.
^C
--- 10.104.61.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1009ms

root@t1:~#
exit

root@server01:~# incus config device override t1 eth0 security.promiscuous=true
Device eth0 overridden for t1
root@server01:~# incus exec t1 bash
root@t1:~# ip link set eth0 address 00:16:3e:f3:d4:30
root@t1:~# ip -4 a add dev eth0 10.104.61.100/24
root@t1:~# ping 10.104.61.1
PING 10.104.61.1 (10.104.61.1) 56(84) bytes of data.
64 bytes from 10.104.61.1: icmp_seq=1 ttl=254 time=1.20 ms
^C
--- 10.104.61.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.197/1.197/1.197/0.000 ms
root@t1:~#

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

Possibilité de désactiver l’allocation d’IP sur les cartes réseau OVN¶

Toujours avec OVN, une nouvelle option permet de désactiver complètement l’allocation d’IP sur une carte réseau.

Cette fonctionnalité va souvent de pair avec la fonctionnalité précédente, puisque les cartes réseau en mode promiscuous n’ont généralement pas besoin d’avoir leurs propres adresses IPv4 et IPv6. Pour gérer cela, il est désormais possible de définir ipv4.address et ipv6.address à none, désactivant les allocations.

Notez qu’OVN ne permet pas de désactiver un seul de ces deux protocoles, donc les deux clefs doivent actuellement être définies à none pour que cela fonctionne.

root@server01:~# incus config device set t1 eth0 ipv4.address=none ipv6.address=none
root@server01:~# incus start t1
root@server01:~# incus exec t1 bash
root@t1:~# ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
root@t1:~#

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

Personnalisation des requêtes de scopes OIDC¶

Il est maintenant possible de configurer la liste des scopes OpenID Connect qui sont requêtées.

Le paramètre oidc.scopes dans la configuration du serveur permet de remplacer la valeur par défaut openid, offline_access, et peut être utile pour obtenir des informations supplémentaires avec des scopes comme profile.

Documentation : https://linuxcontainers.org/incus/docs/main/server_config/#openid-connect-configuration

Configuration de la taille des métadonnées des PV LVM¶

Les très grands groupes de volumes LVM contenant des milliers de volumes logiques peuvent avoir des métadonnées dépassant la taille allouée.

Cette taille était déjà configurable pour les pools LVM en thin provisioning (par défaut), mais pour le thick provisioning, ce n’était pas possible.

Désormais, la clef de configuration lvm.metadata_size peut être définie, pour remplacer la valeur par défaut de LVM.
Notez que cela ne peut être fait qu’à la création du pool.

stgraber@castiana:~$ incus storage create demo lvm lvm.use_thinpool=false
Storage pool demo created
stgraber@castiana:~$ sudo vgs -o name,mda_size
  VG   VMdaSize
  demo  1020.00k
stgraber@castiana:~$ incus storage delete demo
Storage pool demo deleted

stgraber@castiana:~$ incus storage create demo lvm lvm.use_thinpool=false lvm.metadata_size=100MiB
Storage pool demo created
stgraber@castiana:~$ sudo vgs -o name,mda_size
  VG   VMdaSize
  demo  <101.00m
stgraber@castiana:~$ incus storage delete demo
Storage pool demo deleted

Documentation : https://linuxcontainers.org/incus/docs/main/reference/storage_lvm/#configuration-options

Configuration des chemins des sockets OVS¶

Il y a quelques configurations dans lesquelles OpenVSwitch n’est pas lancé à son adresse habituelle.

Le cas le plus courant est celui des utilisateurs de MicroOVN, pour lequel le socket OpenVSwitch est stocké dans /var/snap/microovn/common/....

Jusqu’à présent, il fallait faire des pieds et des mains pour avoir un socket OVS fonctionnel dans /run afin qu’Incus puisse correctement s’y connecter.

Avec ce changement, il est maintenant possible de définir la clef de configuration network.ovs.connection avec un chemin valide de connexion OVSDB, pour permettre à Incus de communiquer avec OpenVSwitch. La valeur par défaut est unix:/run/openvswitch/db.sock.

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

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.5.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.4 est maintenant disponible¶

9 août 2024

Introduction¶

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

Cette version propose des nouveautés très variées pour tout le monde !

Elle contient un certain nombre de corrections de bugs et des nouvelles fonctionnalités relatives au support des conteneurs OCI ajouté dans la version précédente. Elle apporte également de nouvelles fonctionnalités pour les environnements partagés/clusterisés complexes. Enfin, elle est remplie de résolutions de bugs, corrigeant de nombreux irritants autour notamment du stockage, du clustering, de l’authentification OpenID et de l’audit.

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

Nouvelles fonctionnalités¶

Configuration des groupes dans les clusters¶

Les groupes disposent désormais d’une table de configuration standard, comme la plupart des autres objets d’Incus.

Cela vient avec son ensemble habituel de commandes et d’API :

• incus cluster group edit
• incus cluster group get
• incus cluster group set
• incus cluster group show
• incus cluster group unset

Caractéristiques CPU propres à chaque groupe¶

En plus de leur configuration, cette nouvelle version d’Incus permet de définir pour chaque groupe un ensemble de fonctionnalités CPU exposées aux VM.

Il est ainsi possible d’avoir un groupe par modèle/génération de CPU, et de laisser Incus calculer un ensemble de flags CPU commun pour ces serveurs.

Par exemple, incus cluster group set foo instances.vm.cpu.x86_64.baseline=kvm64 instances.vm.cpu.x86_64.flags=auto permet à Incus de parcourir automatiquement les serveurs dans le groupe foo et de le laisser définir la clef de configuration flags avec l’ensemble des flags CPU en commun.

Mais cela permet également de définir votre propre configuration CPU ; par exemple, incus cluster group set foo instances.vm.cpu.x86_64.baseline=EPYCv2 instances.vm.cpu.x86_64.flags=-svm expose un CPU AMD EPYC de base de 2e génération, avec l’extension de virtualisation (svm) désactivée.

Utilisation d’un chemin dans un volume comme un disque¶

Il est maintenant possible d’utiliser un chemin à l’intérieur d’un volume personnalisé comme source dans la définition d’un disque.

stgraber@castiana:~$ incus launch images:ubuntu/24.04 demo
Launching demo
stgraber@castiana:~$ incus launch images:ubuntu/24.04 demo-sub
Launching demo-sub
stgraber@castiana:~$ incus storage volume create default demovol
Storage volume demovol created
stgraber@castiana:~$ incus config device add demo demovol disk pool=default source=demovol path=/mnt/demovol
Device demovol added to demo
stgraber@castiana:~$ incus exec demo bash
root@demo:~# mkdir -p /mnt/demovol/sub/path/
root@demo:~# echo world > /mnt/demovol/sub/path/hello
root@demo:~#·
exit
stgraber@castiana:~$ incus config device add demo-sub demovol disk pool=default source=demovol/sub/path path=/mnt/demovol
Device demovol added to demo-sub
stgraber@castiana:~$ incus exec demo-sub bash
root@demo-sub:~# cat /mnt/demovol/hello·
world

Dans cet exemple, un volume personnalisé demovol est créé, puis attaché au conteneur demo. Un sous-répertoire est créé dans ce volume, et ce sous-répertoire est ensuite attaché à un autre conteneur, demo-sub.

Limites des projets par pool de stockage¶

Les projets dans Incus peuvent se voir appliquer des limites de ressources, ce qui est idéal lorsque l’on donne accès à un projet à un tiers. Jusqu’à présent, il était possible de donner une limite sur l’utilisation disque totale au sein d’un projet, mais elle s’appliquait à chacun des pools de stockage.

Puisqu’il est courant d’avoir différents pools de stockage, représentant différentes caractéristiques (local vs distant) ou classes (ssd vs hdd) de stockage, il est utile d’avoir un moyen de fournir des limites pour chaque pool.

Pour ce faire, une nouvelle clef de configuration pour les projets, limits.disk.pool.POOLNAME, est désormais disponible. Définir la limite à 0 pour un pool le désactive complètement et le fait disparaître de la liste des pools de stockage du projet.

stgraber@dakara:~$ incus project info test-limits
+------------------+-----------+-------+
|     RESOURCE     |   LIMIT   | USAGE |
+------------------+-----------+-------+
| CONTAINERS       | UNLIMITED | 0     |
+------------------+-----------+-------+
| CPU              | UNLIMITED | 0     |
+------------------+-----------+-------+
| DISK             | UNLIMITED | 0B    |
+------------------+-----------+-------+
| INSTANCES        | UNLIMITED | 0     |
+------------------+-----------+-------+
| MEMORY           | UNLIMITED | 0B    |
+------------------+-----------+-------+
| NETWORKS         | UNLIMITED | 0     |
+------------------+-----------+-------+
| PROCESSES        | UNLIMITED | 0     |
+------------------+-----------+-------+
| VIRTUAL-MACHINES | UNLIMITED | 0     |
+------------------+-----------+-------+
stgraber@dakara:~$ incus storage list
+---------+--------+-------------+---------+---------+
|  NAME   | DRIVER | DESCRIPTION | USED BY |  STATE  |
+---------+--------+-------------+---------+---------+
| default | zfs    |             | 45      | CREATED |
+---------+--------+-------------+---------+---------+
| foo     | dir    |             | 0       | CREATED |
+---------+--------+-------------+---------+---------+
stgraber@dakara:~$ incus project set test-limits limits.disk.pool.foo=0 limits.disk.pool.default=5GiB limits.disk=10GiB
stgraber@dakara:~$ incus project info test-limits
+------------------+-----------+-------+
|     RESOURCE     |   LIMIT   | USAGE |
+------------------+-----------+-------+
| CONTAINERS       | UNLIMITED | 0     |
+------------------+-----------+-------+
| CPU              | UNLIMITED | 0     |
+------------------+-----------+-------+
| DISK             | 10.00GiB  | 0B    |
+------------------+-----------+-------+
| DISK (DEFAULT)   | 5.00GiB   | 0B    |
+------------------+-----------+-------+
| INSTANCES        | UNLIMITED | 0     |
+------------------+-----------+-------+
| MEMORY           | UNLIMITED | 0B    |
+------------------+-----------+-------+
| NETWORKS         | UNLIMITED | 0     |
+------------------+-----------+-------+
| PROCESSES        | UNLIMITED | 0     |
+------------------+-----------+-------+
| VIRTUAL-MACHINES | UNLIMITED | 0     |
+------------------+-----------+-------+
stgraber@dakara:~$ incus storage list
+---------+--------+-------------+---------+---------+
|  NAME   | DRIVER | DESCRIPTION | USED BY |  STATE  |
+---------+--------+-------------+---------+---------+
| default | zfs    |             | 45      | CREATED |
+---------+--------+-------------+---------+---------+
stgraber@dakara:~$ incus create images:ubuntu/24.04 c1 --storage default -d root,size=5GiB
Creating c1

The instance you are starting doesn't have any network attached to it.
  To create a new network, use: incus network create
  To attach a network to an instance, use: incus network attach

stgraber@dakara:~$ incus create images:ubuntu/24.04 c2 --storage default -d root,size=5GiB
Creating c2
Error: Failed instance creation: Failed checking if instance creation allowed: Reached maximum aggregate value "5GiB" for "limits.disk.pool.default" in project "test-limits"
stgraber@dakara:~$ incus project set test-limits limits.disk.pool.foo=5GiB
stgraber@dakara:~$ incus create images:ubuntu/24.04 c2 --storage foo -d root,size=5GiB
Creating c2

The instance you are starting doesn't have any network attached to it.
  To create a new network, use: incus network create
  To attach a network to an instance, use: incus network attach

stgraber@dakara:~$ incus project info test-limits
+------------------+-----------+----------+
|     RESOURCE     |   LIMIT   |  USAGE   |
+------------------+-----------+----------+
| CONTAINERS       | UNLIMITED | 2        |
+------------------+-----------+----------+
| CPU              | UNLIMITED | 0        |
+------------------+-----------+----------+
| DISK             | 10.00GiB  | 10.00GiB |
+------------------+-----------+----------+
| DISK (DEFAULT)   | 5.00GiB   | 5.00GiB  |
+------------------+-----------+----------+
| DISK (FOO)       | 5.00GiB   | 5.00GiB  |
+------------------+-----------+----------+
| INSTANCES        | UNLIMITED | 2        |
+------------------+-----------+----------+
| MEMORY           | UNLIMITED | 0B       |
+------------------+-----------+----------+
| NETWORKS         | UNLIMITED | 0        |
+------------------+-----------+----------+
| PROCESSES        | UNLIMITED | 0        |
+------------------+-----------+----------+
| VIRTUAL-MACHINES | UNLIMITED | 0        |
+------------------+-----------+----------+
stgraber@dakara:~$

Ici, un projet est configuré avec une limite de disque, qui cache dans un premier temps l’un des pools et définit une utilisation maximale pour l’autre, puis avec une seconde limite qui s’applique au pool précédemment caché.

Réseaux OVN isolés (sans uplink)¶

Jusqu’à présent, tous les réseaux OVN disposaient d’un réseau uplink (avec la propriété network).
Il s’agit du réseau sur lequel se trouve le port du routeur connecté à l’extérieur, et au travers duquel tout l’ingress/egress vers/depuis le réseau OVN a lieu.

Incus choisit une adresse IPv4 (et/ou IPv6) sur ce réseau uplink et l’utilise pour router le trafic en-dehors du réseau virtuel, vers le réseau physique.

Désormais, une valeur spéciale none pour la propriété network indique à Incus de créer un réseau OVN connecté à aucun uplink, et donc complètement isolé.

root@server01:~# incus network create ovn-isolated network=none --type=ovn
Network ovn-isolated created
root@server01:~# incus launch images:ubuntu/24.04 c1 --network ovn-isolated
Launching c1
root@server01:~# incus list
+------+---------+--------------------+-----------------------------------------------+-----------+-----------+----------+
| NAME |  STATE  |        IPV4        |                     IPV6                      |   TYPE    | SNAPSHOTS | LOCATION |
+------+---------+--------------------+-----------------------------------------------+-----------+-----------+----------+
| c1   | RUNNING | 10.248.34.2 (eth0) | fd42:669c:8431:b3cc:216:3eff:fef3:fdb2 (eth0) | CONTAINER | 0         | server01 |
+------+---------+--------------------+-----------------------------------------------+-----------+-----------+----------+
root@server01:~# incus exec c1 bash
root@c1:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1031ms

Nous créons ici un réseau isolé et y connectons un conteneur.
Ce réseau fournit des adresses IPv4 et IPv6 comme précédemment, mais aucun trafic ne peut en sortir.

LXCFS par instance¶

Une nouvelle clef de configuration du serveur, instances.lxcfs.per_instance, peut désormais être activée pour qu’Incus démarre une instance dédiée de LXCFS pour chaque conteneur.

Cela permet de dévier de la configuration par défaut, dans laquelle une seule instance de LXCFS tourne pour l’ensemble du système.

L’activation de cette option entraîne une utilisation de ressources légèrement plus importante pour chaque conteneur, mais réduit le risque qu’un conteneur sature l’instance LXCFS partagée, cloisonnant ainsi les plantages de LXCFS à un seul conteneur.

stgraber@castiana:~$ pgrep -a lxcfs
1101 /opt/incus/bin/lxcfs /var/lib/incus-lxcfs
stgraber@castiana:~$ incus config set instances.lxcfs.per_instance=true
stgraber@castiana:~$ incus restart demo
stgraber@castiana:~$ pgrep -a lxcfs
1101 /opt/incus/bin/lxcfs /var/lib/incus-lxcfs
962122 lxcfs -f -p /run/incus/demo/lxcfs.pid --runtime-dir /run/incus/demo/lxcfs /var/lib/incus/devices/demo/lxcfs

Définition de variables d’environnement dans un fichier¶

Pour faciliter l’exécution des conteneurs OCI, il est désormais possible de spécifier des variables d’environnement dans un fichier lu à la création du conteneur, et converti en options de configuration d’Incus.

stgraber@castiana:~$ cat mysql.env
MYSQL_DATABASE=wordpress
MYSQL_USER=wordpress
MYSQL_PASSWORD=wordpress
MYSQL_RANDOM_ROOT_PASSWORD=1

stgraber@castiana:~$ incus launch docker:mysql mysql --environment-file mysql.env 
Launching mysql

stgraber@castiana:~$ incus config show mysql
architecture: x86_64
config:
  environment.GOSU_VERSION: "1.17"
  environment.HOME: /root
  environment.MYSQL_DATABASE: wordpress
  environment.MYSQL_MAJOR: innovation
  environment.MYSQL_PASSWORD: wordpress
  environment.MYSQL_RANDOM_ROOT_PASSWORD: "1"
  environment.MYSQL_SHELL_VERSION: 9.0.1-1.el9
  environment.MYSQL_USER: wordpress
  environment.MYSQL_VERSION: 9.0.1-1.el9
  environment.PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  environment.TERM: xterm
  image.architecture: x86_64
  image.description: docker.io/library/mysql (OCI)
  image.type: oci
  volatile.base_image: d8df069848906979fd7511db00dc22efeb0a33a990d87c3c6d3fcdafd6fc6123
  volatile.cloud-init.instance-id: f12e3ddb-ac93-4942-b3e1-dcd560893140
  volatile.container.oci: "true"
  volatile.eth0.host_name: vethac8631aa
  volatile.eth0.hwaddr: 00:16:3e:20:32:87
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.uuid: 5ed7f63b-5b6c-4c89-9dfa-117c2b785370
  volatile.uuid.generation: 5ed7f63b-5b6c-4c89-9dfa-117c2b785370
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""

Dans cet exemple, un conteneur mysql est créé à partir d’une image OCI, avec des variables d’environnement spécifiées dans mysql.env.

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.4.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.3 est maintenant disponible¶

12 juil. 2024

Introduction¶

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

Le point fort de cette version est le début de la prise en charge de l’exécution de conteneurs d’application OCI.
Cela permet l’utilisation d’images Docker/OCI directement sous Incus, avec les conteneurs d’application tournant aux côtés des conteneurs système et des machines virtuelles !

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

Nouvelles fonctionnalités¶

Support des conteneurs d’application OCI¶

Incus est maintenant capable d’accéder à des registres de conteneurs d’application comme le Docker Hub.

C’est le tout début de notre support des conteneurs OCI ; il y aura donc probablement un certain nombre de lacunes à combler suite aux commentaires qui nous seront remontés. En attendant, Incus devrait pouvoir assurer seul de nombreux cas d’usage simples dans lesquels les utilisateurs faisaient tourner à la fois Incus et Docker sur le même système ou faisaient tourner Docker dans un conteneur Incus pour lancer leurs applications.

Toutes les options de configuration des conteneurs Incus, qu’il s’agisse de limites de ressources, d’interceptions de syscalls… s’appliquent également aux conteneurs applicatifs. Ils sont aussi tous lancés dans le même environnement sûr de conteneurisation que nos conteneurs système.

stgraber@dakara:~$ incus remote add docker https://docker.io --protocol=oci
stgraber@dakara:~$ incus launch docker:mysql mysql \
> -c environment.MYSQL_DATABASE=wordpress \
> -c environment.MYSQL_USER=wordpress \
> -c environment.MYSQL_PASSWORD=wordpress \
> -c environment.MYSQL_RANDOM_ROOT_PASSWORD=1
Launching mysql

stgraber@dakara:~$ incus list mysql
+-------+---------+----------------------+------------------------------------------+-----------------+-----------+
| NAME  |  STATE  |         IPV4         |                   IPV6                   |      TYPE       | SNAPSHOTS |
+-------+---------+----------------------+------------------------------------------+-----------------+-----------+
| mysql | RUNNING | 172.17.250.26 (eth0) | 2602:fc62:c:250:216:3eff:fefa:468 (eth0) | CONTAINER (APP) | 0         |
+-------+---------+----------------------+------------------------------------------+-----------------+-----------+

stgraber@dakara:~$ incus launch docker:wordpress wordpress \
> -c environment.WORDPRESS_DB_HOST=172.17.250.26 \
> -c environment.WORDPRESS_DB_USER=wordpress \
> -c environment.WORDPRESS_DB_PASSWORD=wordpress \
> -c environment.WORDPRESS_DB_NAME=wordpress
Launching wordpress

stgraber@dakara:~$ incus list wordpress
+-----------+---------+-----------------------+-------------------------------------------+-----------------+-----------+
|   NAME    |  STATE  |         IPV4          |                   IPV6                    |      TYPE       | SNAPSHOTS |
+-----------+---------+-----------------------+-------------------------------------------+-----------------+-----------+
| wordpress | RUNNING | 172.17.250.119 (eth0) | 2602:fc62:c:250:216:3eff:fe61:c1fc (eth0) | CONTAINER (APP) | 0         |
+-----------+---------+-----------------------+-------------------------------------------+-----------------+-----------+
stgraber@dakara:~$

Clusters de CPU hétérogènes¶

L’une des principales limites dans la logique de migration à chaud d’Incus était que les CPU des différentes machines devaient être identiques. En cas de CPU différents, la migration à chaud échouait ou provoquait des crashs ultérieurement.

Tous les flags CPU de la machine hôte étaient en effet exposés par Incus ; c’est une bonne chose pour obtenir les meilleures performances sur un système isolé, mais dans un cluster hétérogène, cela ne fonctionne pas vraiment.

Avec cette version, Incus calculera automatiquement l’ensemble des flags communs à toutes les machines pour une architecture CPU donnée, et utilisera cet ensemble de flags pour toutes les instances migrables à chaud (migration.stateful=true).

Ajout des options io.bus et io.cache pour les systèmes de fichiers¶

Les options io.bus et io.cache existent depuis un certain temps pour les disques de VM. L’option io.bus peut être définie à virtio-scsi, virtio-blk ou nvme, et l’option io.cache peut être définie à none, writeback ou unsafe.

Ces clefs de configuration sont désormais supportées pour les systèmes de fichiers en plus des disques. Leurs valeurs sont un peu différentes ; io.bus peut être définie à auto (par défaut), 9p ou virtiofs, et io.cache peut être définie à none (par défaut), metadata ou unsafe.

Cela permet de contrôler précisément comment un système de fichiers est exposé à une VM et de modifier le comportement de mise en cache lors de l’utilisation de virtiofs.

Améliorations dans incus top¶

Incus 6.2 a introduit la nouvelle commande incus top.
Avec cette version, nous la rendons plus utile, en lui permettant de fonctionner avec des serveurs distants et des environnements en cluster, et de prendre en charge les projets.

+---------+---------------+-------------+-----------+-----------+
| PROJECT | INSTANCE NAME | CPU TIME(S) |  MEMORY   |   DISK    |
+---------+---------------+-------------+-----------+-----------+
| default | incus-ui      | 63.40       | 12.76MiB  | 1.54GiB   |
+---------+---------------+-------------+-----------+-----------+
| default | kernel-test   | 1865037.10  | 578.01MiB | 32.84GiB  |
+---------+---------------+-------------+-----------+-----------+
| default | speedtest     | 84.10       | 23.14MiB  | 400.12MiB |
+---------+---------------+-------------+-----------+-----------+
| default | win11         | 1865.11     | 15.51GiB  |           |
+---------+---------------+-------------+-----------+-----------+
| demo    | mysql         | 6.77        | 464.20MiB | 276.62MiB |
+---------+---------------+-------------+-----------+-----------+
| demo    | wordpress     | 1.81        | 53.66MiB  | 386.62MiB |
+---------+---------------+-------------+-----------+-----------+
| vpn     | vpn-dev       | 102.97      | 36.83MiB  | 412.00MiB |
+---------+---------------+-------------+-----------+-----------+
| vpn     | vpn-lab       | 57.29       | 27.03MiB  | 347.75MiB |
+---------+---------------+-------------+-----------+-----------+
Press 'd' + ENTER to change delay
Press 's' + ENTER to change sorting method
Press CTRL-C to exit

Delay: 10s
Sorting Method: Alphabetical

Flags CPU dans les ressources des serveurs¶

L’API des ressources, qui est utilisée pour exposer de nombreux détails sur la configuration matérielle des machines, a été mise à jour pour exposer les flags CPU.

Le changement était nécessaire pour l’implémentation de la fonctionnalité présentée plus tôt.
Les nouvelles données peuvent être trouvées directement dans l’API et sont fournies pour chaque cœur CPU.

stgraber@dakara:~$ incus query /1.0/resources | jq .cpu.sockets[0].cores[0].flags -c
["fpu","vme","de","pse","tsc","msr","pae","mce","cx8","apic","sep","mtrr","pge","mca","cmov","pat","pse36","clflush","mmx","fxsr","sse","sse2","ht","syscall","nx","mmxext","fxsr_opt","pdpe1gb","rdtscp","lm","constant_tsc","rep_good","nopl","xtopology","nonstop_tsc","cpuid","extd_apicid","aperfmperf","rapl","pni","pclmulqdq","monitor","ssse3","fma","cx16","sse4_1","sse4_2","x2apic","movbe","popcnt","aes","xsave","avx","f16c","rdrand","lahf_lm","cmp_legacy","svm","extapic","cr8_legacy","abm","sse4a","misalignsse","3dnowprefetch","osvw","ibs","skinit","wdt","tce","topoext","perfctr_core","perfctr_nb","bpext","perfctr_llc","mwaitx","cpb","cat_l3","cdp_l3","hw_pstate","ssbd","mba","ibrs","ibpb","stibp","vmmcall","fsgsbase","bmi1","avx2","smep","bmi2","erms","invpcid","cqm","rdt_a","rdseed","adx","smap","clflushopt","clwb","sha_ni","xsaveopt","xsavec","xgetbv1","xsaves","cqm_llc","cqm_occup_llc","cqm_mbm_total","cqm_mbm_local","clzero","irperf","xsaveerptr","rdpru","wbnoinvd","cppc","arat","npt","lbrv","svm_lock","nrip_save","tsc_scale","vmcb_clean","flushbyasid","decodeassists","pausefilter","pfthreshold","avic","v_vmsave_vmload","vgif","v_spec_ctrl","umip","pku","ospke","vaes","vpclmulqdq","rdpid","overflow_recov","succor","smca","fsrm","debug_swap"]

Prise en charge des images unifiées dans incus-simplestreams¶

L’outil incus-simplestreams, utilisé pour gérer un serveur web statique hébergeant des images Incus en utilisant le format d’indexation simplestreams, a été mis à jour pour supporter à la fois les images séparées et les images unifiées.

Les images Incus peuvent être composées de deux fichiers, l’un contenant les fichiers de métadonnées et l’autre contenant le rootfs ou le disque racine, ou d’un seul tarball contenant à la fois les métadonnées et le rootfs ou le disque racine.

Aboutissement de la transition vers libovsdb¶

Depuis les 4–5 dernières versions, nous avons progressivement réduit notre usage des outils en ligne de commande ovs-vsctl, ovn-nbctl et ovn-sbctl pour nous tourner vers un client OVSDB natif.

Ce travail est maintenant terminé et Incus ne nécessite plus la présence des outils OVS/OVN sur la machine pour interagir avec OVN.

La nouvelle logique maintient une connexion persistante avec les bases de données idoines, réduisant considérablement le temps et la charge CPU nécessaires à interagir avec OVN. Cette connexion persistante permettra également de recevoir directement les événements d’OVN et d’y réagir, ce qui n’était pas possible avec l’approche précédente.

Avis pour les packagers¶

Cette version introduit le support d’OCI, qui nécessite la présence des commandes skopeo et umoci dans le PATH pour que la fonctionnalité soit opérante.

De plus, la variable d’environnement INCUS_OVMF_PATH a été renommée en INCUS_EDK2_PATH, afin d’éviter l’utilisation d’un nom spécifique à une architecture (arm64 utilise AAVMF) pour se baser plutôt sur le nom générique du firmware.

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.3.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.1 LTS est maintenant disponible¶

28 juin 2024

Introduction¶

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

C’est la première 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 :

• Syntaxe étendue pour les pools ZFS (permettant de créer des miroirs et des raidz1/raidz2)
• Listage de tous les objets (instances, profils, images, volumes/buckets de stockage, réseaux…) sur tous les projets
• Fonctions supplémentaires exposées au scriptlet de placement des instances
• Support du YAML en entrée de toutes les sous-commandes create de la CLI
• Customisation des colonnes pour toutes les sous-commandes list de la CLI
• Extension de la clef de configuration migration.stateful aux conteneurs
• Support des ACL réseau stateless dans OVN
• Ajout d’un timestamp pour mesurer l’uptime des instances
• Nouvelle commande incus top (utilisant l’API des métriques existante)
• Affichage de la charge système dans incus info --resources
• Affichage des périphériques PCI dans incus info --resources
• Possibilité de requêter qui a accès à tel projet ou instance
• Suppression forcée de projets
• Amélioration de la gestion des alias dans incus-simplestreams

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

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.1.tar.xz
• Signature GPG : incus-6.0.1.tar.xz.asc

Incus 6.2 est maintenant disponible¶

31 mai 2024

Introduction¶

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

Cette version contient la deuxième vague de contributions des étudiants de l’Université du Texas à Austin ainsi que quelques autres fonctionnalités et améliorations.

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

Nouvelles fonctionnalités¶

Nouvelle commande incus top¶

Une nouvelle commande incus top a été ajoutée. Elle utilise l’endpoint OpenMetrics d’Incus et permet de consulter en temps réel des statistiques sur les instances, notamment l’utilisation CPU, RAM et disque.

+---------------+-------------+-----------+-----------+
| INSTANCE NAME | CPU TIME(S) |  MEMORY   |   DISK    |
+---------------+-------------+-----------+-----------+
| foo           | 6.73        | 12.44MiB  | 341.88MiB |
+---------------+-------------+-----------+-----------+
| speedtest     | 32.79       | 23.84MiB  | 373.50MiB |
+---------------+-------------+-----------+-----------+
| v1            | 67130.91    | 254.54MiB | 1.25GiB   |
+---------------+-------------+-----------+-----------+
Press 'd' + ENTER to change delay
Press 's' + ENTER to change sorting method
Press CTRL-C to exit

Delay: 5s
Sorting Method: Alphabetical

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

Informations sur la charge des serveurs dans l’API des ressources¶

Une nouvelle section a été ajoutée à l’API des ressources pour exposer les informations sur la charge des serveurs (1 min, 5 min, 10 min) ainsi que le nombre total de processus.

Ces informations sont particulièrement utiles pour le placement des instances et l’équilibrage automatique des hôtes, car elles permettent d’avoir un bon aperçu de l’activité des différents serveurs directement à partir de l’API d’Incus.

stgraber@castiana:~$ incus info --resources
System:
  UUID: 05006c9c-7863-ee11-9e1b-224425600022
  Vendor: Framework
  Product: Laptop 13 (AMD Ryzen 7040Series)
  Family: Laptop
  Version: A5
  SKU: FRANDGCP05
  Serial: FRANDGCPA5340500AZ
  Type: physical
  Chassis:
      Vendor: Framework
      Type: Notebook
      Version: A5
      Serial: FRANDGCPA5340500AZ
  Motherboard:
      Vendor: Framework
      Product: FRANMDCP05
      Serial: FRANMDCPA534040120
      Version: A5
  Firmware:
      Vendor: INSYDE Corp.
      Version: 03.05
      Date: 03/29/2024

Load:
  Processes: 519
  Average: 0.80 0.77 0.71

[snip...]

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

Possibilité d’interroger les ACL des instances et projets¶

Deux nouvelles API ont été ajoutées pour permettre d’interroger les ACL des projets et des instances.

La fonctionnalité s’intègre à notre support d’OpenFGA et, avec une version suffisamment récente d’OpenFGA, vous montrera exactement qui peut accéder à une instance et quel est son rôle.

stgraber@castiana:~$ incus info --show-access foo
- identifier: stgraber@stgraber.org
  role: admin
  provider: openfga

stgraber@castiana:~$ incus project info --show-access default
- identifier: stgraber@stgraber.org
  role: admin
  provider: openfga

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

Suppression forcée de projets¶

Lorsque l’on a affaire à un grand nombre de projets très chargés, leur suppression peut devenir assez frustrante car il faut identifier et supprimer tout ce qu’ils contiennent dans le bon ordre.

Pour remédier à cela, nous avons à présent la commande incus project delete --force, qui demandera à Incus de tout supprimer dans le bon ordre avant de supprimer le projet lui-même.

L’opération est bien entendu très dangereuse. L’outil en ligne de commande vous demandera toujours de confirmer que vous souhaitez bien procéder à la suppression complète du projet.

stgraber@castiana:~$ incus project delete demo
Error: Only empty projects can be removed.

stgraber@castiana:~$ incus project delete demo --force
Remove demo and everything it contains (instances, images, volumes, networks, ...) (yes/no): yes
Project demo deleted

Nouvelle fonction get_project pour les scriptlets¶

Pour les personnes utilisant notre fonctionnalité de placement d’instances par scriplet (instances.placement.scriptlet), une nouvelle fonction a été ajoutée, get_project.

Elle permet de récupérer tous les détails (api.Project) d’un projet donné et est particulièrement utile si vous souhaitez que les restrictions ou les limites du projet aient un impact sur la décision de placement.

Documentation : https://linuxcontainers.org/incus/docs/main/explanation/clustering/#instance-placement-scriptlet
Ce travail a été mené par des étudiants de l’Université du Texas à Austin.

Interrogation des objets sur tous les projets¶

Incus permet depuis longtemps de lister toutes les instances, quel que soit le projet.
Récemment, cette fonctionnalité a été étendue aux volumes de stockage, aux images, aux profils, aux zones réseau et aux opérations en cours.

Avec Incus 6.2, toutes les collections d’objets manquantes prennent désormais en charge cette fonctionnalité :

• Buckets de stockage
• Réseaux
• ACL réseau

L’interface en ligne de commande a été mise à jour, de sorte que toutes les commandes list montrant des objets spécifiques à un projet supportent maintenant --all-projects.

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

Périphériques PCI dans incus info --resources¶

Tous les périphériques PCI sont désormais inclus dans la sortie de incus info --resources.
Auparavant, seuls les périphériques inclus dans les sections GPU ou disque étaient disponibles.

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

Amélioration de la gestion des alias dans incus-simplestreams¶

L’implémentation initiale d’incus-simplestreams générait automatiquement un alias de la forme DISTRIBUTION/RELEASE/VARIANT, mais ce n’est pas adapté à tous les environnements. Il y a donc maintenant deux nouveaux arguments pour la commande incus-simplestreams add :

• --no-default-alias pour désactiver l’alias automatique
• --alias pour définir un alias personnalisé (l’argument peut être passé plusieurs fois)

Utilisation de YAML avec les commandes create¶

Ce travail a été commencé avec Incus 6.1 et est maintenant terminé.

Toutes les commandes create ainsi que incus init et incus launch acceptent désormais des fichiers YAML dans leur entrée standard.

Cela facilite grandement l’écriture de scripts pour des déploiements complexes.

Customisation des colonnes des commandes list¶

Voici un autre travail commencé dans Incus 6.1 qui est maintenant terminé.

Toutes les commandes d’Incus qui ont une fonction list prennent désormais en charge l’option --column/-c.

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

Documentation générée de manière plus automatique¶

La plupart des personnes utilisant Incus ne devraient pas remarquer ce changement. Nous avons progressivement fait évoluer notre documentation pour qu’elle soit générée automatiquement à partir des commentaires dans notre code, limitant ainsi le risque qu’elle devienne obsolète ou désynchronisée.

Avec Incus 6.2, les éléments de documentation suivants sont générés de cette manière :

• Zones réseau
• Restrictions d’images
• Limites du noyau
• Périphériques
  • disk
  • unix-block
  • unix-char
  • unix-hotplug
  • usb

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.2.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¶

• 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