Actualités¶

Incus 6.8 est maintenant disponible¶

13 déc. 2024

Introduction¶

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

Il s’agit de la dernière version de 2024, et elle vient avec son lot de nouveautés : la possibilité de déplacer une VM en fonctionnement sur un autre pool de stockage, un nouveau backend d’autorisation, des améliorations dans la gestion des volumes pour les conteneurs d’application, et bien d’autres.

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

Joyeuses fêtes !

Nouvelles fonctionnalités¶

Migration à chaud de pool de stockage pour les VM¶

Il est désormais possible de déplacer une VM entre deux pools de stockage différents sans l’arrêter.
Notez cependant que pour éviter d’avoir deux instances de QEMU exécutant la même VM sur le même serveur, celle-ci doit être également migrée vers un autre serveur du même cluster.

Le déplacement d’un pool à l’autre se fait ainsi :

incus move NOM --storage NOUVEAU-POOL --target AUTRE-SERVEUR

Scriptlet d’autorisation¶

Une nouvelle méthode d’autorisation a été ajoutée, sous la forme d’un scriptlet d’autorisation.
Cela permet d’avoir un mécanisme d’autorisation personnalisé, qui peut être combiné à l’authentification TLS ou OIDC.

Documentation : https://linuxcontainers.org/incus/docs/main/authorization/#scriptlet-authorization

Capture d’écran des consoles des VM¶

Pour simplifier le développement d’interfaces graphiques et de clients web pour Incus, nous avons à présent une manière simple de prendre des captures d’écran des consoles VGA des VM.

Cette opération a l’avantage d’être assez simple et peut être effectuée même lorsqu’un utilisateur est connecté à la console VGA.

Pour récupérer une capture d’écran d’une VM en PNG, il suffit de faire une requête GET /1.0/instances/NOM/console?type=vga.

Propriétaire et mode initiaux pour des volumes de stockage personnalisés¶

Pour simplifier la création de volumes de stockage personnalisés pour stocker les données des conteneurs OCI, plusieurs nouvelles options ont été ajoutées :

• initial.uid
• initial.gid
• initial.mode

Ces options peuvent être passées à la création d’un volume, et, comme leurs noms le suggèrent, définissent les valeurs initiales de l’uid, du gid, et du mode du répertoire racine du volume.

Exemple :

incus storage volume create default my-volume size=5GiB initial.uid=1000 initial.gid=1000 initial.mode=0700

Mises à jour du modèle OpenFGA¶

Le modèle d’accès OpenFGA a été légèrement modifié dans cette version.

La permission initiale user:* viewer server:incus, qui permettait un accès en lecture seule aux ressources globales pour tous les utilisateurs authentifiés, a été remplacée par la permission équivalente user:* authenticated server:incus.

En parallèle, la permission viewer peut être désormais directement assignée aux utilisateurs et donne un accès en lecture seule complet sur le serveur (et plus seulement aux ressources globales).

La permission sera automatiquement modifiée lors de la mise à jour.

De plus, un nouveau droit can_view_sensitive a été ajouté afin de permettre le contrôle de qui peut lire les informations sensibles de configuration, comme la configuration du serveur.

Import d’image avec réutilisation d’alias¶

Comme c’était le cas pour incus publish, il est maintenant possible de lancer incus image import --reuse --alias ALIAS image.tar.xz pour importer une image en remplaçant celle qui était identifiée par l’alias ALIAS.

Nouvelle commande incus-simplestreams prune¶

Une nouvelle commande incus-simplestreams prune a été ajoutée pour nettoyer les serveurs simplestreams. Lorsque la commande est lancée, celle-ci identifie et nettoie :

• Les fichiers d’images qui n’appartiennent à aucune image dans l’index
• Les entrées d’index pour lesquelles des fichiers d’images sont manquantes
• Les anciennes entrées d’index (par défaut, les 2 précédentes images sont conservées)

Verrouillage de l’accès console¶

L’accès à la console a toujours été limité à un unique utilisateur à la fois.
Cependant, la personne se connectant en dernier récupérait toujours le contrôle sur la console.

Puisque cela était souvent la source de surprises et de problèmes, l’accès à la console est désormais protégé. Lorsque l’on tente de se connecter alors qu’une session est déjà active, une erreur est retournée ; la connexion peut être forcée avec l’option correspondante.

Exemple :

incus console remote-server:windows-2022 --force

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

15 nov. 2024

Introduction¶

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

Cette version est encore une fois très complète, avec de nouvelles fonctionnalités et des améliorations pour tout le monde, des personnes opérant des nœuds standalone à des clusters à grande échelle, en passant par les homelabs ; il y en a pour tous les goûts !

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

Nouvelles fonctionnalités¶

Accès simplifié à l’interface web d’Incus¶

Un irritant qui revient souvent est la difficulté d’accès à l’interface web d’Incus.

En effet, par défaut, Incus n’écoute pas sur le réseau. C’est seulement après avoir été configuré à cet effet qu’il offre un accès en HTTPS, et si vous n’opérez pas un serveur d’authentification OpenID Connect, l’authentification ne se fait qu’avec des certificats client TLS.

C’est tout à fait faisable, mais le processus est assez fastidieux :

1. Ouvrir l’accès au réseau à Incus
2. Accéder à l’interface web
3. Ignorer l’alerte du navigateur
4. Générer un certificat client
5. Configurer Incus pour accepter sa clef publique
6. Importer la paire de clefs publique + privée dans le navigateur
7. Recharger le navigateur et espérer que l’authentification fonctionne

Désormais, une alternative nettement plus simple est proposée, sans compromis sur la sécurité, en lançant incus webui.

L’exécution de cette commande permet au client Incus d’exécuter un petit serveur web HTTP sur un port aléatoire du périphérique de loopback. L’accès à ce serveur web est limité à un token unique, pour empêcher une autre personne ou un autre logiciel d’interagir avec Incus sans autorisation. Lorsque le bon token est utilisé, toutes les interactions sont proxifiées au serveur Incus en utilisant les mêmes identifiants que l'outil client.

Rééquilibrage automatique de cluster¶

Puisque les clusters Incus supportent la migration à chaud de VM et proposent une logique de placement flexible et des mécanismes de réparation automatique lorsqu’un serveur est indisponible, la suite logique est d’ajouter un mécanisme de rééquilibrage automatique.

C’est désormais possible par l’intermédiaire des options de configuration suivantes :

• cluster.rebalance.batch contrôle combien d’instances peuvent être déplacées en même temps
• cluster.rebalance.cooldown contrôle le temps à attendre avant de déplacer à nouveau une instance
• cluster.rebalance.interval contrôle la fréquence à laquelle les instances sont déplacées
• cluster.rebalance.threshold contrôle la différence (en pourcents) de charge entre deux serveurs requise pour déclencher un rééquilibrage

Incus calcule un score pour chaque serveur au sein d’un cluster, puis compare le score le plus haut avec celui le plus bas. Si la différence est supérieure au seuil défini, cela déclenche le déplacement de certaines instances entre les serveurs.

Le score est basé sur la charge moyenne à 1 minute, et est ajusté par rapport au nombre de CPU et à la RAM disponible.

Seules les VM migrables à chaud sont déplacées, et seulement lorsque toutes les exigences relatives à la migration sont respectées, que ce soit dans leurs configuration ou dans les restrictions de leurs projets.

Documentation : https://linuxcontainers.org/incus/docs/main/howto/cluster_manage/#cluster-re-balancing

Renouvellement de baux DHCP pour les conteneurs OCI¶

Un problème récurrent avec les conteneurs OCI dans Incus est que ceux-ci gèrent rarement leur configuration réseau ; ils s’attendent à démarrer avec une stack réseau fonctionnelle (adresse, routes, DNS).

Pour que cela fonctionne, Incus lançait un petit client DHCP durant l’initialisation de l’instance, afin de configurer le réseau. Cette initialisation du réseau n’avait lieu qu’une seule fois, ce qui posait problème lorsque les baux DHCP n’étaient pas renouvelés, avec notamment des enregistrements DNS expirés.

Depuis Incus 6.7, le client DHCP continue à tourner en arrière-plan dans le conteneur, afin de gérer le renouvellement des baux.

Rafraîchissement partiel d’instances et de volumes¶

Pour sauvegarder des instances, une fonctionnalité souvent utilisée est de faire copy --refresh vers une cible distante, ce qui permet de transférer tous les instantanés manquants sur la cible en les comparant avec ceux du serveur source, puis de synchroniser l’état courant.

Cela fonctionne plutôt bien, mais dans certains cas, il est sensé de procéder à un nettoyage des vieux instantanés du serveur de sauvegarde. Malheureusement, l’opération de rafraîchissement suivante resynchronisera les vieux instantanés supprimés, même s’ils ne sont plus utiles.

Une solution évidente est d’également supprimer les vieux instantanés sur le serveur source, mais il peut être raisonnable de vouloir les garder, pour avoir plus d’historique que sur le serveur de sauvegarde.

L’option --refresh-exclude-older a pour cela été ajoutée. En combinaison avec --refresh, elle permet de ne transférer que les instantanés créés depuis l’instantané le plus récent du serveur cible, ignorant ainsi les anciens instantanés manquants.

Colonnes, formattage et temps de rafraîchissement configurables pour incus top¶

incus top se rajoute à la longue liste de commandes à supporter --format et --columns, permettant de personnaliser le retour de la commande.

De plus, une option --refresh permet désormais de piloter la période de rafraîchissement de la commande.

Support pour les plages d’adresses DHCP dans les réseaux OVN¶

L’option de configuration ipv4.dhcp.ranges s’applique maintenant également aux réseaux OVN.

Cela permet de ne réserver qu’une partie du sous-réseau pour l’allocation dynamique d’adresses IP, laissant le reste pour les adresses définies statiquement, et d’autres usages.

Changement du périphérique parent pour les réseaux physiques¶

Il est maintenant possible de changer la valeur de la propriété parent sur les réseaux de type physical. Cela permet de déplacer un réseau uplink OVN vers un périphérique différent, ce qui peut arriver lorsque le réseau physique est reconfiguré ou qu’une carte réseau physique est remplacée.

Fonctions QMP additionnelles pour le scriptlet QEMU¶

Un certain nombre de fonctions supplémentaires sont maintenant disponibles pour le scriptlet QEMU.

Parmi celles-ci, la fonction run_command permet de simplifier l’utilisation de run_qmp pour l’exécution de commandes simples.

De plus, les commandes suivantes ont été ajoutées :

• blockdev_add
• blockdev_del
• chardev_add
• chardev_change
• chardev_remove
• device_add
• device_del
• netdev_add
• netdev_del
• object_add
• object_del
• qom_get
• qom_list
• qom_set

Nouveau fichier de journal pour les commandes QMP¶

Un nouveau fichier, qemu.qmp.log, est maintenant disponible pour les machines virtuelles. Celui-ci garde en mémoire la plupart des interactions entre Incus et QEMU.

root@castiana:~# incus list v1
+------+---------+-----------------------+-------------------------------------------------+-----------------+-----------+
| NAME |  STATE  |         IPV4          |                      IPV6                       |      TYPE       | SNAPSHOTS |
+------+---------+-----------------------+-------------------------------------------------+-----------------+-----------+
| v1   | RUNNING | 10.178.240.4 (enp5s0) | fd42:8384:a6f8:63a0:216:3eff:fe4d:5cad (enp5s0) | VIRTUAL-MACHINE | 0         |
+------+---------+-----------------------+-------------------------------------------------+-----------------+-----------+
root@castiana:~# cat /var/log/incus/v1/qemu.qmp.log 
[2024-11-15T13:11:52-05:00] QUERY: {"execute":"query-cpus-fast"}
[2024-11-15T13:11:52-05:00] REPLY: {"return": [{"thread-id": 443303, "props": {"core-id": 0, "thread-id": 0, "node-id": 0, "socket-id": 0}, "qom-path": "/machine/unattached/device[0]", "cpu-index": 0, "target": "x86_64"}]}

[2024-11-15T13:11:52-05:00] QUERY: {"execute":"netdev_add","arguments":{"fds":"/dev/net/tun.0:/dev/net/tun.1","id":"incus_eth0","type":"tap","vhost":true,"vhostfds":"/dev/vhost-net.0:/dev/vhost-net.1"}}
[2024-11-15T13:11:52-05:00] REPLY: {"return": {}}

[2024-11-15T13:11:52-05:00] QUERY: {"execute":"device_add","arguments":{"addr":"00.0","bootindex":"1","bus":"qemu_pcie4","driver":"virtio-net-pci","id":"dev-incus_eth0","mac":"00:16:3e:4d:5c:ad","mq":"on","netdev":"incus_eth0","vectors":"6"}}
[2024-11-15T13:11:52-05:00] REPLY: {"return": {}}

[2024-11-15T13:11:52-05:00] QUERY: {"execute":"blockdev-add","arguments":{"aio":"native","cache":{"direct":true,"no-flush":false},"discard":"unmap","driver":"host_device","filename":"/dev/fdset/0","locking":"off","node-name":"incus_root","read-only":false}}
[2024-11-15T13:11:52-05:00] REPLY: {"return": {}}

[2024-11-15T13:11:52-05:00] QUERY: {"execute":"device_add","arguments":{"bootindex":"0","bus":"qemu_scsi.0","channel":"0","drive":"incus_root","driver":"scsi-hd","id":"dev-incus_root","lun":"1","serial":"incus_root"}}
[2024-11-15T13:11:52-05:00] REPLY: {"return": {}}

[2024-11-15T13:11:52-05:00] QUERY: {"execute":"system_reset"}
[2024-11-15T13:11:52-05:00] REPLY: {"return": {}}

[2024-11-15T13:11:52-05:00] QUERY: {"execute":"set-action","arguments":{"panic":"pause","reboot":"shutdown","shutdown":"poweroff"}}
[2024-11-15T13:11:52-05:00] REPLY: {"return": {}}

[2024-11-15T13:11:52-05:00] QUERY: {"execute":"cont"}
[2024-11-15T13:11:52-05:00] REPLY: {"return": {}}

[2024-11-15T13:11:52-05:00] QUERY: {"execute":"query-status"}
[2024-11-15T13:11:52-05:00] REPLY: {"return": {"status": "running", "running": true}}

Nouvelle commande get_instances_count pour le scriptlet de placement d’instances¶

Une nouvelle fonction get_instances_count a été ajoutée au scriptlet de placement d’instances.

Elle permet de récupérer le nombre d’instances global, ou au sein d’un serveur (location) ou d’un projet (project), ou une combinaison des deux. Il est également possible d’inclure dans le compte les instances en cours de création (pending).

Avec cette nouvelle fonctionnalité, un changement a été apporté à la liste des candidats fournie au scriptlet : celle-ci est désormais triée en fonction du nombre d’instances que chaque candidat contient (par ordre croissant).

Support de l’option --format dans incus admin sql¶

incus admin sql supporte désormais l’option --format.

Celle-ci est particulièrement utile si l’on sélectionne une colonne SQL unique, tout en utilisant --format=csv. Il est alors possible d’obtenir des valeurs brutes directement passables à l’entrée d’un autre script.

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

Anciennes nouvelles¶

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