Actualités¶

Incus 6.6 est maintenant disponible¶

3 oct. 2024

Introduction¶

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

C’est une version un peu moins chargée cette fois, principalement en raison du voyage à la Linux Plumbers Conference et des événement associés il y a quelques semaines.

Mais c’est loin d’être une version ennuyeuse. En plus des corrections habituelles de bugs et de l’amélioration des performances, nous avons un certain nombre de nouveautés intéressantes pour les machines virtuelles, un meilleur support des clusters LVM, des améliorations pour incus-migrate, et de nouvelles fonctionnalités réseau !

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

Nouvelles fonctionnalités¶

Informations sur l’OS des machines virtuelles¶

L’agent des VM Incus a été étendu pour obtenir des informations supplémentaires sur chaque machine virtuelle.

stgraber@dakara:~$ incus info v1
Name: v1
Status: RUNNING
Type: virtual-machine
Architecture: x86_64
PID: 3753543
Created: 2024/09/24 10:02 EDT
Last Used: 2024/10/03 11:29 EDT
Started: 2024/10/03 11:29 EDT

Operating System:
  OS: Ubuntu
  OS Version: 24.04.1 LTS (Noble Numbat)
  Kernel Version: 6.10.11-zabbly+
  Hostname: v1
  FQDN: v1

Resources:
  Processes: 35
  Disk usage:
    root: 1.02GiB
  CPU usage:
    CPU usage (in seconds): 4
  Memory usage:
    Memory (current): 374.78MiB
  Network usage:
    enp5s0:
      Type: broadcast
      State: UP
      Host interface: tap84ebf5ff
      MAC address: 00:16:3e:75:89:6e
      MTU: 1500
      Bytes received: 3.13kB
      Bytes sent: 1.30kB
      Packets received: 27
      Packets sent: 12
      IP addresses:
        inet:  172.17.250.94/24 (global)
        inet6: 2602:fc62:c:250:216:3eff:fe75:896e/64 (global)
        inet6: fe80::216:3eff:fe75:896e/64 (link)
    lo:
      Type: loopback
      State: UP
      MTU: 65536
      Bytes received: 5.92kB
      Bytes sent: 5.92kB
      Packets received: 80
      Packets sent: 80
      IP addresses:
        inet:  127.0.0.1/8 (local)
        inet6: ::1/128 (local)

Pour l’instant, ces informations ne sont disponibles que pour les machines virtuelles, car les conteneurs n’exécutent pas d’agent, et que récupérer ces informations depuis le système de fichiers du conteneur peut être risqué.

Historique de la console des machines virtuelles¶

L’accès à la console des conteneurs a toujours été assez flexible, avec à la fois un accès interactif (incus console) et un journal textuel non interactif (incus console --show-log).

Pour les machines virtuelles cependant, les choses étaient un peu plus limitées, car QEMU ne permettait pas de simultanément envoyer les informations de la console à un périphérique interactif et enregistrer les données dans un tampon circulaire.

Mais nous avons depuis trouvé un moyen de faire fonctionner cela, en faisant basculer QEMU entre un backend interactif et un tampon circulaire, selon que quelqu’un est connecté ou non à la console.

En conséquence, incus console --show-log fonctionne désormais aussi pour les machines virtuelles !

stgraber@dakara:~$ incus console --show-log v1
BdsDxe: loading Boot0006 "Ubuntu" from HD(1,GPT,B7DD04C0-15CE-482C-A6AC-7278FDA10CF6,0x800,0x32000)/\EFI\ubuntu\shimx64.efi
BdsDxe: starting Boot0006 "Ubuntu" from HD(1,GPT,B7DD04C0-15CE-482C-A6AC-7278FDA10CF6,0x800,0x32000)/\EFI\ubuntu\shimx64.efi
rootfs: clean, 58918/6393600 files, 1074908/13081339 blocks

Ubuntu 24.04.1 LTS v1 ttyS0

v1 login:

Possibilité de créer des groupes de volumes LVM en cluster¶

Incus supporte les clusters LVM depuis plusieurs versions, mais jusqu’à présent, le groupe de volumes partagé devait être créé en amont par les utilisateurs.

Désormais, Incus permet de spécifier directement le périphérique partagé de stockage par bloc, et il créera automatiquement le groupe de volumes.

root@server01:~# incus storage create demo-lvm lvmcluster source=/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_incus_demo--shared --target server01
Storage pool demo-lvm pending on member server01
root@server01:~# incus storage create demo-lvm lvmcluster source=/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_incus_demo--shared --target server02
Storage pool demo-lvm pending on member server02
root@server01:~# incus storage create demo-lvm lvmcluster source=/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_incus_demo--shared --target server03
Storage pool demo-lvm pending on member server03
root@server01:~# incus storage create demo-lvm lvmcluster source=/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_incus_demo--shared --target server04
Storage pool demo-lvm pending on member server04
root@server01:~# incus storage create demo-lvm lvmcluster
Storage pool demo-lvm created

Support de QCOW2 et VMDK dans incus-migrate¶

L’outil incus-migrate peut désormais importer des images de machines virtuelles QCOW2 et VMDK. Pour cela, il faut que l’outil qemu-img soit disponible sur le système, afin de gérer la conversion.

root@dakara:~# incus-migrate 
The local Incus server is the target [default=yes]: 
Would you like to create a container (1) or virtual-machine (2)?: 2
Project to create the instance in [default=default]: 
Name of the new instance: foo
Please provide the path to a disk, partition, or qcow2/raw/vmdk image file: /home/stgraber/demo/rhel9.qcow2
Does the VM support UEFI booting? [default=yes]: 
Does the VM support UEFI Secure Boot? [default=yes]:

Instance to be created:
  Name: foo
  Project: default
  Type: virtual-machine
  Source: /home/stgraber/demo/rhel9.qcow2
  Source format: qcow2

Additional overrides can be applied at this stage:
1) Begin the migration with the above configuration
2) Override profile list
3) Set additional configuration options
4) Change instance storage pool or volume size
5) Change instance network

Please pick one of the options above [default=1]:  
Converting image "/home/stgraber/demo/rhel9.qcow2" to raw format before importing
Instance foo successfully created

Mode macvlan configurable¶

Jusqu’à présent, le mode macvlan était toujours défini à bridged.
Il est désormais possible d’utiliser d’autres modes, comme vepa, passthru ou private.

stgraber@dakara:~$ incus create images:ubuntu/24.04 c1
Creating c1
stgraber@dakara:~$ incus config device add c1 eth0 nic nictype=macvlan parent=enp35s0 mode=private name=eth0
Device eth0 added to c1
stgraber@dakara:~$ incus start c1

Informations sur l’état des load-balancers¶

Avec l’ajout récent de la surveillance de l’état des load-balancers OVN, il était logique d’étendre l’API afin d’y exposer cet état.

root@server01:~# incus network load-balancer show default 172.31.254.50
description: ""
config:
  healthcheck: "true"
backends:
- name: c1
  description: ""
  target_port: ""
  target_address: 10.104.61.10
- name: c2
  description: ""
  target_port: ""
  target_address: 10.104.61.11
ports:
- description: ""
  protocol: tcp
  listen_port: "80"
  target_backend:
  - c1
  - c2
- description: ""
  protocol: tcp
  listen_port: "22"
  target_backend:
  - c1
  - c2
listen_address: 172.31.254.50
location: ""

root@server01:~# incus network load-balancer info default 172.31.254.50
Backend health:
  c1 (10.104.61.10):
    - tcp/80: online
    - tcp/22: offline

  c2 (10.104.61.11):
    - tcp/80: offline
    - tcp/22: online

Interfaces externes pour les réseaux OVN¶

Il est maintenant possible d’attacher une interface physique externe d’un serveur à un réseau OVN virtuel. Cela permet de faire le lien entre le réseau physique et le réseau virtuel.

root@server01:~# incus network set bar bridge.external_interfaces=foo --target server02
root@server01:~# incus network info bar
Name: bar
MAC address: 00:16:3e:e6:b6:10
MTU: 1422
State: up
Type: broadcast

IP addresses:
  inet  10.179.82.1/24 (link)
  inet6 fd42:3f01:28ef:4257::1/64 (link)

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

OVN:
  Chassis: server01
  Logical router: incus-net25-lr
root@server01:~# ovn-nbctl lsp-list incus-net25-ls-int
e7070089-c979-4bc1-b6f2-1f63008af44b (incus-net25-external-n2-foo)
65eba7f1-e150-4dce-b054-180e389e4d58 (incus-net25-ls-int-lsp-router)

Évacuation/restauration d’un cluster en parallèle¶

L’évacuation et la restauration d’un cluster peuvent être des opérations assez longues, en particulier dans les clusters faisant tourner un grand nombre d’instances.

Pour améliorer cela, nous allons désormais automatiquement paralléliser ce processus.
Afin de limiter l’impact, la parallélisation est faite de manière assez conservatrice, en n’ajoutant qu’un niveau de parallélisation pour 16 threads CPU. Ainsi, même les serveurs les plus puissants avec 512 threads ne verront que 32 instances déplacées simultanément.

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.6.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.2 LTS est maintenant disponible¶

17 sept. 2024

Introduction¶

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

Il s’agit de la deuxiè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 :

• Fin de la transition vers OVSDB pour OVS/OVN
• Clusters de CPU hétérogènes
• Ajout des options io.bus et io.cache pour les systèmes de fichiers
• Flags CPU dans les ressources des serveurs
• Prise en charge des images unifiées dans incus-simplestreams
• Aboutissement de la transition vers libovsdb
• Utilisation d’un chemin dans un volume comme un disque
• Limites des projets par pool de stockage
• Réseaux OVN isolés (sans uplink)
• LXCFS par instance
• Définition de variables d’environnement dans un fichier
• Redémarrage automatique d’instances
• Sélection des colonnes dans toutes les commandes de listage
• Hooks et scriptlet QMP
• Support du redimensionnement des disques à chaud pour les machines virtuelles
• Hotplug des périphériques PCI
• Surveillance de l’état des load-balancers OVN
• Mode promiscuous pour les cartes réseau OVN
• Possibilité de désactiver l’allocation d’IP sur les cartes réseau OVN
• Personnalisation des requêtes de scopes OIDC
• Configuration de la taille des métadonnées des PV LVM
• Configuration des chemins des sockets OVS

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

Avis pour les packagers¶

Dans cette version, 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.

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

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

Anciennes nouvelles¶

• 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