News¶

Incus 6.6 has been released¶

Oct 3, 2024

Introduction¶

The Incus team is pleased to announce the release of Incus 6.6!

A slightly less busy release this time, mostly due to traveling to the Linux Plumbers Conference and associated events a few weeks ago.

But still far from a boring release. On top of the usual bugfix and performance improvements, we're getting a number of nice additions for virtual machines, improved clustered LVM support, improvements to incus-migrate and a number of new network features!

As usual, you can try it for yourself online: https://linuxcontainers.org/incus/try-it/

Enjoy!

New features¶

OS info for virtual machines¶

The Incus VM agent has been extended to pull some additional details about the virtual machine.

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)

This information is only available for virtual machines at this time as containers don't run an agent and directly fetching that information from the container's filesystem can be unsafe.

Console history for virtual machines¶

Console access with containers has always been pretty flexible with both interactive access (incus console) and non-interactive text log (incus console --show-log) both being available.

For virtual machines however, things were a bit more limited as QEMU didn't allow us to simultaneously send the console to an interactive device as well as recording everything into a ring buffer.

But we have since found a way to make it work by having QEMU switch between an interactive backend and a ringbuffer depending on whether someone is connected to the console.

The end result is that incus console --show-log now works for virtual machines too!

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:

Ability to create clustered LVM volume groups¶

Incus has supported clustered LVM for a few releases now, but up until now, the shared volume group had to be pre-created by the user.

Now Incus allows you to directly specify the shared block device and have it create the volume group.

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

QCOW2 and VMDK support in incus-migrate¶

The standalone incus-migrate tool can now import existing QCOW2 and VMDK based virtual machines. This relies on qemu-img being available on the system to handle the 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

Configurable macvlan mode¶

Up until now, the macvlan mode was always fixed to bridged.
This can now be customized, allowing the other modes, such as vepa, passthru and private to be used too.

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

Load-balancer health information¶

With the recent addition of health monitoring to our OVN load-balancers, it made sense to further extend the API to also expose that health information.

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

External interfaces for OVN networks¶

It's now possible to attach an external physical interface on a specific server to a virtual OVN network. This allows bridging the gap between physical and virtual networking.

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)

Parallel cluster evacuation/restore¶

Cluster evacuation and restoration can be a pretty lengthy process, especially on clusters running a lot of instances.

To improve this, we will now automatically parallelize this process.
In order to limit the impact, this is done pretty conservatively and only adds an extra parallel migration per 16 CPU threads. So even one of the beefiest servers out there with 512 threads will only see 32 instances be moved concurrently.

Complete changelog¶

Here is a complete list of all changes in this release:

Documentation¶

The Incus documentation can be found at:
https://linuxcontainers.org/incus/docs/main/

Packages¶

There are no official Incus packages as Incus upstream only releases regular release tarballs. Below are some available options to get Incus up and running.

Installing the Incus server on Linux¶

Incus is available for most common Linux distributions. You'll find detailed installation instructions in our documentation.

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

Homebrew package for the Incus client¶

The client tool is available through HomeBrew for both Linux and MacOS.

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

Chocolatey package for the Incus client¶

The client tool is available through Chocolatey for Windows users.

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

Winget package for the Incus client¶

The client tool is also available through Winget for Windows users.

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

Support¶

Monthly feature releases are only supported up until the next release comes out. Users needing a longer support length and less frequent changes should consider using Incus 6.0 LTS instead.

Community support is provided at: https://discuss.linuxcontainers.org
Commercial support is available through: https://zabbly.com/incus
Bugs can be reported at: https://github.com/lxc/incus/issues

Incus 6.0.2 LTS has been released¶

Sep 17, 2024

Introduction¶

The Incus team is pleased to announce the release of Incus 6.0.2!

This is the second bugfix release for Incus 6.0 which is supported until June 2029.

Changes¶

As usual this bugfix releases focus on stability and hardening.

Minor improvements have also been backported, specifically anything which does not require data migration, database changes or cause any unexpected change to user facing behavior.

The number of such improvements will decrease over time within the LTS branch.

Some of the highlights for this release are:

• Completion of transition to native OVSDB for OVS/OVN
• Baseline CPU defintiion for clustered users
• Filesystem support for io.bus and io.cache
• CPU flags in server resources
• Unified image support in incus-simplestreams
• Completion of libovsdb transition
• Using a sub-path of a volume as a disk
• Per storage pool projects limits
• Isolated OVN networks (no uplink)
• Per-instance LXCFS
• Support for environment file at create/launch time
• Instance auto-restart
• Column selection in all list commands
• QMP command hooks and scriptlet
• Live disk resize support in virtual machines
• PCI devices hotplug
• OVN load-balancer health checks
• Promiscuous mode for OVN NICs
• Ability to run off IP allocation on OVN NICs
• Customizable OIDC scope request
• Configurable LVM PV metadata size
• Configurable OVS socket path

The full list of commits is available below:

Notice for packagers¶

With this release, the INCUS_OVMF_PATH environment variable was renamed to INCUS_EDK2_PATH to avoid the use of the architecture-specific name (arm64 uses AAVMF) and instead rely on the generic name of the firmware.

Support and upgrade¶

The Incus 6.0 branch is supported until June 2029. It's always strongly recommended to keep up and run the latest LTS bugfix release.

Downloads¶

• Main release tarball: incus-6.0.2.tar.xz
• GPG signature: incus-6.0.2.tar.xz.asc

Incus 6.5 has been released¶

Sep 6, 2024

Introduction¶

The Incus team is pleased to announce the release of Incus 6.5!

A strong focus for this release was on performance. Costly internal calls like resolving large number of profiles and devices have been optimized significantly leading to up to a 20-30x performance improvement. Similarly, handling of systems with thousands of instances per server has also been greatly improved, cutting down startup checks from tens of minutes down to tens of seconds.

But this isn't just a bugfix release, Incus 6.5 also introduces quite a few new features and other improvements. From making our CLI experience more consistent, to making it easier to perform low-level actions on virtual machines, to improving the life of application container users and through a number of great new features for OVN users, this release should have something for everyone!

As usual, you can try it for yourself online: https://linuxcontainers.org/incus/try-it/

Enjoy!

New features¶

Instance auto-restart¶

A common request ever since we first rolled out application containers support in Incus, the ability to have instances automatically restart when they exit makes it easier to handle applications crashing or reloading.

This is controlled through a new boot.autorestart configuration key which when set to true will have Incus attempt to restart a given instance up to 10 times over a 1 minute time span.

User requested instance shutdown/stop do not trigger the auto-restart logic.

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

Column selection in all list commands¶

Over the past few releases, we've been working on improving the consistency of the incus CLI commands. This started with making sure that all our list commands support --format and now with this release, all list commands also now support --columns.

This allows for easily customizing the output you're getting, as well as making it much easier to script the incus command by combining both --format=csv with --column= to select just the relevant column(s).

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

QMP command hooks and scriptlet¶

Incus currently relies on QEMU to run its virtual machines.

The way Incus interacts with QEMU can be a bit complex at times as it's effectively done through three different mechanisms:

• QEMU command line
• QEMU configuration file
• QEMU Machine Protocol (QMP)

We usually try to avoid polluting the command line as much as possible, so this is kept to a minimum, but we allow the user to pass in additional arguments through raw.qemu.

Our preference for any device which doesn't need live-updating or doesn't need to ever be hotplugged or hot removed is the use of the QEMU configuration file. This is easily templated and can pretty easily be tested. We have the raw.qemu.conf configuration option that can be used to extend or override the content of that configuration file.

And then we have QMP which we use for anything hotpluggable, so effectively all disks, network interfaces, USB devices or any other PCI devices. As the QEMU team is slowly trying to deprecate the configuration file, we expect to progressively be moving more and more of the VM configuration over to QMP.

The main issue with QMP so far has been that unlike the QEMU command line or a config file, it's very opaque. It's not possible to easily see what's been configured and because any of those objects will have been configured after QEMU started, it wasn't possible to override or re-configure them through the existing mechanisms.

But things are different now thanks to a few new configuration options:

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

The first three take a JSON list of QMP commands. QMP commands are normally already all JSON encoded, so that makes it easy to add a number of custom commands to the instance configuration. The commands will be run in order at one of the specified times.

early runs prior to Incus having added anything through QMP, pre-start runs after Incus has added all its devices through QMP and post-start runs immediately after QEMU was instructed to start the VM.

raw.qemu.scriptlet is an even more flexible option as it takes a sriptlet (python-like syntax) which must define a function named qemu_hook and passes it the stage as an argument. That stage is one of early, pre-start or post-start. The different between that and the raw.qemu.qmp options is that a scriptlet can handle command responses and have logic to react to it.

That means that this QEMU scriptlet can call the run_qmp command, pass a custom QMP command, read through its return value and issue more commands if needed, allowing for dynamic re-configuration of the VM.

Note that this is a very low level mechanism which we only expect expert users to use in very specific cases. As with any raw configuration key, its use is effectively unsupported by the Incus team and it should also be kept disabled for any untrusted projects.

Live disk resize support in virtual machines¶

It's now possible to resize either the VM root disk or any attached disk and have the VM be notified of the change. This then causes the operating system to update the size of the disk and allows the user to immediately make use of the additional space without having to restart the 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:~#

PCI devices hotplug¶

Adding and removing PCI devices on a VM can now be done live.
This now matches the behavior found in NIC, GPU and disk devices.

OVN load-balancer health checks¶

Incus' support for OVN load-balancers has so far been pretty basic, essentially being limited to just basic load-balancing of traffic on a set of target with no monitoring of the backend.

But this is now changing with initial support for OVN's load-balancer health checks.
This is configured through a set of configuration keys on the load-balancer:

• healthcheck => Enables health checking
• healthcheck.failure_count => Number of failed attempts to consider backend as failed
• healthcheck.interval => How often to check the backends (in seconds)
• healthcheck.success_count => Number of successful attempts to consider backend as online
• healthcheck.timeout => How long to wait for a response before considering it failed

Only healthcheck is required, all the others have reasonable defaults.

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/

ECMP support for OVN interconnect¶

The network integration support for OVN interconnect has been extended in a few small ways:

• The ovn.transit.pattern configuration option now supports a new peerName variable
• It's now possible to have multiple peers on a network targeting the same network integration
• IP allocation on the transit switch is now recorded directly in the OVN database rather than relying on random subnets

The end result is that it's now possible to change the default core.transit.pattern to include peerName in the template and then add multiple peers to a network, all pointing to the same interconnection.

This internally will result in mutliple transit switches being created and so long as the peer names match on all participating systems, traffic will be balanced between those switches through ECMP.

Doing so allows for very effective load-balancing of interconnection traffic.

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/

Promiscuous mode for OVN NICs¶

A new security.promiscuous configuration key is now available on OVN NICs.

When it's enabled, any OVN traffic that has an unknown MAC address as its destination will now be sent over to the OVN NIC.

The main use for this is for nested environments where you want to have some nested containers or VMs directly sit on the parent OVN network without having their own dedicated ports.
This is typically a development/testing use case as promiscuous mode causes a lot of unnecessary network traffic to hit the NIC.

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

Ability to run off IP allocation on OVN NICs¶

Another new OVN NIC option is the ability to turn off IP allocation completely.

This is often related to the previous case where a promiscuous NIC typically doesn't need to have its own IPv4 and IPv6 address. To handle this, it's now possible to set both ipv4.address and ipv6.address to none, disabling allocations.

Note that OVN doesn't allow disabling just one protocol, so both keys must currently be set to none for this to work.

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

Customizable OIDC scope request¶

It's now possible to configure the list of OpenID Connect Scopes that are being requested.

Setting oidc.scopes in the server config will override the default of openid, offline_access and can be useful to pull in additional information through scopes like profile.

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

Configurable LVM PV metadata size¶

Very very large LVM volumes groups containing thousands of logical volumes may exceed the reserved metadata size.

This was already configurable on LVM thin provisioned pools (default), but for thick provisioning, there was no matching configuration.

Now the lvm.metadata_size configuration key can be set to override LVM's default.
Note that this can only be done at creation time.

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

Configurable OVS socket path¶

There are a few cases where OpenVSwitch doesn't run at the usual address.

The most common case of this would be MicroOVN users where the OpenVSwitch socket is instead stored within /var/snap/microovn/common/....

Until now, those users had to jump through some hoops to get a working OVS socket in /run so Incus would properly connect to it.

With this change, it's now possible to set the network.ovs.connection configuration key to a valid OVSDB connection string and have Incus reach OpenVSwitch through that. The default value is unix:/run/openvswitch/db.sock.

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

Complete changelog¶

Here is a complete list of all changes in this release:

Documentation¶

The Incus documentation can be found at:
https://linuxcontainers.org/incus/docs/main/

Packages¶

There are no official Incus packages as Incus upstream only releases regular release tarballs. Below are some available options to get Incus up and running.

Installing the Incus server on Linux¶

Incus is available for most common Linux distributions. You'll find detailed installation instructions in our documentation.

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

Homebrew package for the Incus client¶

The client tool is available through HomeBrew for both Linux and MacOS.

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

Chocolatey package for the Incus client¶

The client tool is available through Chocolatey for Windows users.

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

Winget package for the Incus client¶

The client tool is also available through Winget for Windows users.

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

Support¶

Monthly feature releases are only supported up until the next release comes out. Users needing a longer support length and less frequent changes should consider using Incus 6.0 LTS instead.

Community support is provided at: https://discuss.linuxcontainers.org
Commercial support is available through: https://zabbly.com/incus
Bugs can be reported at: https://github.com/lxc/incus/issues

Incus 6.4 has been released¶

Aug 9, 2024

Introduction¶

The Incus team is pleased to announce the release of Incus 6.4!

This is a very balanced release with something new for everyone!

It comes with a number of bugfixes and new features to help with the OCI support added in the previous release. It also brings in a number of new features for more complex shared/cluster environments. And it's jam packed with bugfixes, fixing a lot of annoyances around storage, clustering, OpenID authentication, auditing and more.

As usual, you can try it for yourself online: https://linuxcontainers.org/incus/try-it/

Enjoy!

New features¶

Cluster group configuration¶

Cluster groups now have a standard configuration table like most other Incus objects.

This means the usual set of commands and APIs:
- incus cluster group edit
- incus cluster group get
- incus cluster group set
- incus cluster group show
- incus cluster group unset

Per-cluster group CPU baseline and flags for VMs¶

Building on top of that support for cluster group configuration, we now have support for defining the VM CPU baseline on a per cluster group basis.

This makes it possible to have one cluster group per CPU model/generation and have Incus compute the common set of CPU flags for those servers.

For example, incus cluster group set foo instances.vm.cpu.x86_64.baseline=kvm64 instances.vm.cpu.x86_64.flags=auto will have Incus automatically go through the servers in the foo cluster group and then fill in the flags configuration key with the set of common CPU flags.

But this also allows setting up your own completely custom CPU defintion, for example, incus cluster group set foo instances.vm.cpu.x86_64.baseline=EPYCv2 instances.vm.cpu.x86_64.flags=-svm will expose a basic 2nd generation AMD EPYC CPU with the virtualization extension (svm) disabled.

Using a sub-path of a volume as a disk¶

It's now possible to use a path within an existing custom volume as the source for a disk entry.

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

In this example, a demovol custom volume is created, then attached to the demo container, a sub-directory is created in that volume and that sub-directory is then attached to another container, demo-sub.

Per storage pool projects limits¶

Incus projects can have resource limits applied to them, ideal when providing access to a project to a third party. Up until now, it was possible to limit the total disk usage within a project, but that would apply to all storage pools.

As it's common to have different storage pools representing different storage characteristics (local vs remote) or class (ssd vs hdd), it's useful to have a way to provide limits per storage pool.

To do so, a new configuration key, limits.disk.pool.POOLNAME is now available in project configuration. Setting the limit to 0 fully disables that storage pool and causes it to disappear from the storage pool listing in that project.

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:~$

Here we can see a project get set up with a disk limit, first hiding one of the pools, then filling the other before setting a limit on the previously hidden pool.

Isolated OVN networks (no uplink)¶

Up until now, all OVN networks have had a uplink network set (network property).
That's the network on which the external facing router port will sit and through which all ingress/egress into/out-of the OVN network will happen.

Incus picks an IPv4 (and/or IPv6) address on that uplink network and then uses it to route all the traffic out of the virtual network and onto the physical network.

Now a special value of none for that network property will instruct Incus to create an OVN network which is not connected to any uplink and is threfore fully isolated.

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

Here we can see an isolated network being created and a container being placed on it.
The network provides IPv4 and IPv6 addresses as usual, but no traffic can come out.

Per-instance LXCFS¶

A new server configuration key, instances.lxcfs.per_instance can now be enabled to have Incus start a dedicated LXCFS instance for every container.

This is in contrast to the default of having a single LXCFS instance run for the entire system.

Enabling this comes at a slightly higher resource usage per container, but reduces the risk of one container flooding the shared LXCFS instance as well as make it so a LXCFS crash only affects one container.

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

Support for environment file at create/launch time¶

To make it easier to run OCI containers, it's now possible to specify environment variables through an environment variable file which gets read at creation time and converted to Incus configuration options.

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: ""

In this example, we see a mysql container created from an OCI image and using environment variables defined in mysql.env.

Complete changelog¶

Here is a complete list of all changes in this release:

Documentation¶

The Incus documentation can be found at:
https://linuxcontainers.org/incus/docs/main/

Packages¶

There are no official Incus packages as Incus upstream only releases regular release tarballs. Below are some available options to get Incus up and running.

Installing the Incus server on Linux¶

Incus is available for most common Linux distributions. You'll find detailed installation instructions in our documentation.

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

Homebrew package for the Incus client¶

The client tool is available through HomeBrew for both Linux and MacOS.

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

Chocolatey package for the Incus client¶

The client tool is available through Chocolatey for Windows users.

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

Winget package for the Incus client¶

The client tool is also available through Winget for Windows users.

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

Support¶

Monthly feature releases are only supported up until the next release comes out. Users needing a longer support length and less frequent changes should consider using Incus 6.0 LTS instead.

Community support is provided at: https://discuss.linuxcontainers.org
Commercial support is available through: https://zabbly.com/incus
Bugs can be reported at: https://github.com/lxc/incus/issues

Incus 6.3 has been released¶

Jul 12, 2024

Introduction¶

The Incus team is pleased to announce the release of Incus 6.3!

The highlight for this release is the initial support for running OCI application containers.
This allows the use of common Docker/OCI images directly through Incus, with those containers living alongside our usual system containers and virtual machines!

As usual, you can try it for yourself online: https://linuxcontainers.org/incus/try-it/

Enjoy!

New features¶

Initial support for OCI application containers¶

Incus is now capable of accessing application container registries such as the Docker Hub, retrieve images, convert (flatten) them for use by Incus and then create a working containers from them.

This is still very early in our OCI container support and there will likely be quite a few gaps that will need to be filled in based on user feedback, but for many simple cases where people are currently running both Docker and Incus on the same system or where they've been using Docker inside of an Incus container just to run a single piece of software, Incus should now be able to handle that directly.

All of the Incus container configuration options, whether resource limits, system call interception, ... all apply to those containers too. They're also all run in the same safe container environment as our system containers.

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:~$

Baseline CPU definition within clusters¶

One big limitation of Incus' live migration logic so far has been that it expected all servers within a cluster to run identical CPUs. Should the CPU differ between two systems, the live migration would fail or cause crashes later on.

That's because Incus would always expose all the CPU flags from the machine it runs on.
This is good to get the maximum amount of performance on a standalone system, but in a heterogeneous cluster, this doesn't quite work.

With this release, Incus will now automatically compute the set of common CPU flags across all servers for a given CPU architecture and use that as the CPU definition for any instance running with live-migration enabled (migration.stateful=true).

Filesystem support for io.bus and io.cache¶

The io.bus and io.cache options have been around for VM disks for a little while now.
With io.bus offering the option of virtio-scsi, virtio-blk or nvme and io.cache allowing for none, writeback or unsafe caching.

Those config keys are now also supported when passing in filesystems rather than disks.
Their values in such cases are a bit different with io.bus being one of auto (default), 9p or virtiofs and io.cache supporting none (default), metadata or unsafe.

This effectively allows controlling exactly how a filesystem is exposed to the VM and then tweaking caching behavior when using virtiofs.

Improvements to incus top¶

Incus 6.2 introduced the new incus top command.
With this release, we're making it more useful by having it work against remote servers, properly support clustered environments and also handling projects.

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

CPU flags in server resources¶

The resources API which is used to expose a lot of details about the machine's hardware configuration has now been updated to expose the CPU flags.

This was required to implement the baseline CPU feature mentioned previously.
The new data can be found in the API directly and is provided for each CPU core.

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"]

Unified image support in incus-simplestreams¶

The incus-simplestreams tool which is used to manage a static web server hosting Incus images using the simplestreams index format has now been updated to support not just split images but also unified images.

Incus images can either be made of two files, one containing the metadata files and one containing the rootfs or root disk, or a single tarball which contains both the metadata and then the rootfs or root disk as a directory/file inside of that single tarball.

To add a unified image to the server, simply call incus-simplestreams add with a single file rather than the usual two.

Completion of libovsdb transition¶

For the past 4-5 releases, we've been slowly migrating more and more logic from direct calls to the ovs-vsctl, ovn-nbctl and ovn-sbctl command line tools to instead using a native OVSDB client.

This work is now complete and Incus no longer requires any of the OVS/OVN tools be present on the system to interact with OVN.

The new logic keeps a persistent connection to the relevant databases, significantly reducing the time and CPU overhead needed to interact with OVN. This persistent connection will also allow receiving and reacting to events directly from OVN, something which wasn't possible with the previous approach.

Notice for packagers¶

This release introduces OCI support which requires the presence of both skopeo and umoci as commands in the PATH for the feature to work.

Additionally, the INCUS_OVMF_PATH environment variable was renamed to INCUS_EDK2_PATH to avoid the use of the architecture-specific name (arm64 uses AAVMF) and instead rely on the generic name of the firmware.

Complete changelog¶

Here is a complete list of all changes in this release:

Documentation¶

The Incus documentation can be found at:
https://linuxcontainers.org/incus/docs/main/

Packages¶

There are no official Incus packages as Incus upstream only releases regular release tarballs. Below are some available options to get Incus up and running.

Installing the Incus server on Linux¶

Incus is available for most common Linux distributions. You'll find detailed installation instructions in our documentation.

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

Homebrew package for the Incus client¶

The client tool is available through HomeBrew for both Linux and MacOS.

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

Chocolatey package for the Incus client¶

The client tool is available through Chocolatey for Windows users.

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

Winget package for the Incus client¶

The client tool is also available through Winget for Windows users.

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

Support¶

Monthly feature releases are only supported up until the next release comes out. Users needing a longer support length and less frequent changes should consider using Incus 6.0 LTS instead.

Community support is provided at: https://discuss.linuxcontainers.org
Commercial support is available through: https://zabbly.com/incus
Bugs can be reported at: https://github.com/lxc/incus/issues

Older news¶

• Jun 28, 2024
• May 31, 2024
• May 7, 2024
• Apr 4, 2024
• Mar 26, 2024
• Feb 23, 2024
• Jan 29, 2024
• Jan 26, 2024
• Dec 21, 2023
• Nov 27, 2023
• Oct 28, 2023
• Oct 7, 2023