`incus image list` doesn't show the variant

Just a minor niggle here.

I’m using the OS variant to distinguish between various images which have the same base, but are configured in different ways. I’m publishing them through a simplestreams server.

When I do incus image list on a target server which has downloaded and cached an image, I don’t see the variant:

$ incus image list
+-------+--------------+--------+-------------------------------------+--------------+-----------+-----------+----------------------+
| ALIAS | FINGERPRINT  | PUBLIC |             DESCRIPTION             | ARCHITECTURE |   TYPE    |   SIZE    |     UPLOAD DATE      |
+-------+--------------+--------+-------------------------------------+--------------+-----------+-----------+----------------------+
|       | e7a4a6f79003 | no     | vtp-gns3 26.08 amd64 (202608101039) | x86_64       | CONTAINER | 415.83MiB | 2026/08/10 10:51 UTC |
+-------+--------------+--------+-------------------------------------+--------------+-----------+-----------+----------------------+

Furthermore, there doesn’t seem to be a column display option to show the variant (nor the os or release for that matter):

$ incus image list --help
...
  Default column layout is: lfpdasu

  Column shorthand chars:
      l - Shortest image alias (and optionally number of other aliases)
      L - Newline-separated list of all image aliases
      f - Fingerprint (short)
      F - Fingerprint (long)
      p - Whether image is public
      d - Description
      e - Project
      a - Architecture
      s - Size
      u - Upload date
      t - Type

I can see it with incus image info of course, but then I have to query each image individually.

$ incus image info e7a4a6f79003
...
Properties:
    os: vtp-gns3
    release: 26.08
    serial: 202608101039
    type: tar.gz
    variant: cndo
    architecture: amd64
    description: vtp-gns3 26.08 amd64 (202608101039)

It’s less of a problem on the server where I build the image, because I include the variant as part of the description:

$ incus image list e7a4a6f79003
+---------------+--------------+--------+---------------------------------------------------+--------------+-----------+-----------+----------------------+
|     ALIAS     | FINGERPRINT  | PUBLIC |                    DESCRIPTION                    | ARCHITECTURE |   TYPE    |   SIZE    |     UPLOAD DATE      |
+---------------+--------------+--------+---------------------------------------------------+--------------+-----------+-----------+----------------------+
| cndo (1 more) | e7a4a6f79003 | yes    | Virtual Training Platform - cndo (20260810_10:39) | x86_64       | CONTAINER | 415.83MiB | 2026/08/10 10:40 UTC |
+---------------+--------------+--------+---------------------------------------------------+--------------+-----------+-----------+----------------------+

However, the description gets stripped when it’s published to simplestreams, and the client synthesizes its own description locally:

$ incus image list nsrc: e7a4a6f79003
+---------------+--------------+--------+-------------------------------------+--------------+-----------+-----------+----------------------+
|     ALIAS     | FINGERPRINT  | PUBLIC |             DESCRIPTION             | ARCHITECTURE |   TYPE    |   SIZE    |     UPLOAD DATE      |
+---------------+--------------+--------+-------------------------------------+--------------+-----------+-----------+----------------------+
| cndo (3 more) | e7a4a6f79003 | yes    | vtp-gns3 26.08 amd64 (202608101039) | x86_64       | CONTAINER | 415.83MiB | 2026/08/10 00:00 UTC |
+---------------+--------------+--------+-------------------------------------+--------------+-----------+-----------+----------------------+

The synthesized description contains the os, release, and architecture, but not the variant.

As you can see, I’ve also put the variant in an alias, but the alias is also lost by the time the image is downloaded and cached.

I’m thinking two things here:

  1. incus-simplestreams client could include the variant in the “description” that it synthesizes (possibly omitting it if the value is “default”); and/or
  2. incus image list could have additional column flags for properties os, release and variant

What do you think?


P.S. This applies to the official published images too. Simple reproducer:

$ incus create images:ubuntu/26.04 foo
Creating foo
$ incus create images:ubuntu/26.04/cloud bar
Creating bar
$ incus image list
+-------+--------------+--------+----------------------------------------+--------------+-----------+-----------+----------------------+
| ALIAS | FINGERPRINT  | PUBLIC |              DESCRIPTION               | ARCHITECTURE |   TYPE    |   SIZE    |     UPLOAD DATE      |
+-------+--------------+--------+----------------------------------------+--------------+-----------+-----------+----------------------+
|       | 0e40a7057d51 | no     | Ubuntu resolute amd64 (20260810_07:42) | x86_64       | CONTAINER | 164.49MiB | 2026/08/10 11:12 UTC |
+-------+--------------+--------+----------------------------------------+--------------+-----------+-----------+----------------------+
|       | c5b287394c61 | no     | Ubuntu resolute amd64 (20260810_07:42) | x86_64       | CONTAINER | 131.45MiB | 2026/08/10 11:12 UTC |
+-------+--------------+--------+----------------------------------------+--------------+-----------+-----------+----------------------+

One of those images is the cloud variant, and one the default, but as far as I can see, incus image list can’t produce a listing that distinguishes them.

We could expand incus image list to allow for custom columns similar to what we have in incus list.

At least the property based filtering does seem to work fine:

stgraber@vorash-d13:~$ incus image list images: os=Debian variant=cloud arch=amd64 release=trixie type=virtual-machine
+--------------------------------+--------------+--------+--------------------------------------+--------------+-----------------+-----------+----------------------+
|             ALIAS              | FINGERPRINT  | PUBLIC |             DESCRIPTION              | ARCHITECTURE |      TYPE       |   SIZE    |     UPLOAD DATE      |
+--------------------------------+--------------+--------+--------------------------------------+--------------+-----------------+-----------+----------------------+
| debian/13/cloud/amd64 (1 more) | c2d34dfb440c | yes    | Debian trixie amd64 (20260810_05:24) | x86_64       | VIRTUAL-MACHINE | 377.39MiB | 2026/08/09 20:00 EDT |
+--------------------------------+--------------+--------+--------------------------------------+--------------+-----------------+-----------+----------------------+
|                                | 4062f40d7ecf | yes    | Debian trixie amd64 (20260809_05:52) | x86_64       | VIRTUAL-MACHINE | 377.21MiB | 2026/08/08 20:00 EDT |
+--------------------------------+--------------+--------+--------------------------------------+--------------+-----------------+-----------+----------------------+
|                                | f7ffbb44860b | yes    | Debian trixie amd64 (20260808_05:24) | x86_64       | VIRTUAL-MACHINE | 377.15MiB | 2026/08/07 20:00 EDT |
+--------------------------------+--------------+--------+--------------------------------------+--------------+-----------------+-----------+----------------------+
stgraber@vorash-d13:~$ 

Thanks.

And what about adding the variant to the simplestreams “description” field? That seems like it should be simple, albeit at the cost of some extra column width for those with variant != default.

In fact, looking at the distrobuilder source, it looks like it does something like that already:

        if d.Image.Description == "" {
                d.Image.Description = "{{ image.distribution|capfirst }} {{ image.release }} {{ image.architecture_mapped }}{% if image.variant != \"default\" %} ({{ image.variant }}){% endif %} ({{ image.serial }})"
        }

…although the description is lost by the time it goes through simplestreams publishing, I believe.

Sorry to interrupt the subject but what version of incus is this?

indiana@debian:~$ incus image list images: os=Fedora architecture=aarch64 type=virtual-machine
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
|          ALIAS           | FINGERPRINT  | PUBLIC |           DESCRIPTION            | ARCHITECTURE |      TYPE       |   SIZE    |     UPLOAD DATE      |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
| fedora/43/arm64 (1 more) | 9a45afb26e9e | yes    | Fedora 43 arm64 (20260809_20:33) | aarch64      | VIRTUAL-MACHINE | 690.87MiB | 2026/08/09 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
| fedora/43/cloud/arm64    | 66b97f9b4835 | yes    | Fedora 43 arm64 (20260809_20:33) | aarch64      | VIRTUAL-MACHINE | 725.62MiB | 2026/08/09 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
| fedora/44/arm64 (1 more) | b63d3be0fee8 | yes    | Fedora 44 arm64 (20260809_20:33) | aarch64      | VIRTUAL-MACHINE | 709.03MiB | 2026/08/09 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
| fedora/44/cloud/arm64    | e092c52f77f7 | yes    | Fedora 44 arm64 (20260809_20:33) | aarch64      | VIRTUAL-MACHINE | 744.31MiB | 2026/08/09 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
|                          | 22d478bf8bf6 | yes    | Fedora 43 arm64 (20260806_20:55) | aarch64      | VIRTUAL-MACHINE | 690.67MiB | 2026/08/06 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
|                          | 49fb66c59038 | yes    | Fedora 43 arm64 (20260806_20:33) | aarch64      | VIRTUAL-MACHINE | 725.62MiB | 2026/08/06 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
|                          | 9375b7b1244b | yes    | Fedora 44 arm64 (20260807_20:33) | aarch64      | VIRTUAL-MACHINE | 708.63MiB | 2026/08/07 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
|                          | afc35cd5429c | yes    | Fedora 44 arm64 (20260806_20:33) | aarch64      | VIRTUAL-MACHINE | 709.16MiB | 2026/08/06 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
|                          | b3e1d644ec3b | yes    | Fedora 43 arm64 (20260807_20:33) | aarch64      | VIRTUAL-MACHINE | 691.00MiB | 2026/08/07 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
|                          | b63c7af1e94d | yes    | Fedora 44 arm64 (20260807_20:33) | aarch64      | VIRTUAL-MACHINE | 744.08MiB | 2026/08/07 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
|                          | d1ce7d424aa7 | yes    | Fedora 44 arm64 (20260806_20:33) | aarch64      | VIRTUAL-MACHINE | 744.03MiB | 2026/08/06 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+
|                          | ee85bd9e0c6f | yes    | Fedora 43 arm64 (20260807_20:33) | aarch64      | VIRTUAL-MACHINE | 725.28MiB | 2026/08/07 03:00 +03 |
+--------------------------+--------------+--------+----------------------------------+--------------+-----------------+-----------+----------------------+

$ incus image list images: os=Fedora arch=aarch64 type=virtual-machine
+-------+-------------+--------+-------------+--------------+------+------+-------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
+-------+-------------+--------+-------------+--------------+------+------+-------------+

try arch=arm64

Yeah, we can tweak the shared/simplestreams handling to include the variant field if present.

o/

Will it be possible to extend the version display to OCI as well?

The example below is llama.cpp/docs/docker.md at master · ggml-org/llama.cpp · GitHub ; they use version tags to distribute their OCI images. b77ef7aef37f is the toolkit (‘full’), eed756bff457 is the server, but its not possible to tell with the current output.

kgoetz@L23001:~$ incus image ls n23002: --all-projects
+--------------------+-------+--------------+--------+-------------------------------------+--------------+-----------------+------------+-----------------------+
|      PROJECT       | ALIAS | FINGERPRINT  | PUBLIC |             DESCRIPTION             | ARCHITECTURE |      TYPE       |    SIZE    |      UPLOAD DATE      |
+--------------------+-------+--------------+--------+-------------------------------------+--------------+-----------------+------------+-----------------------+
| Internal |       | 905da17dd159 | no     | Ubuntu noble amd64 (20260810_07:42) | x86_64       | VIRTUAL-MACHINE | 289.97MiB  | 2026/08/10 23:31 AEST |
+--------------------+-------+--------------+--------+-------------------------------------+--------------+-----------------+------------+-----------------------+
| Internal |       | b77ef7aef37f | no     | ghcr.io/ggml-org/llama.cpp (OCI)    | x86_64       | CONTAINER       | 1080.53MiB | 2026/08/10 17:34 AEST |
+--------------------+-------+--------------+--------+-------------------------------------+--------------+-----------------+------------+-----------------------+
| Internal |       | eed756bff457 | no     | ghcr.io/ggml-org/llama.cpp (OCI)    | x86_64       | CONTAINER       | 544.42MiB  | 2026/08/10 17:32 AEST |
+--------------------+-------+--------------+--------+-------------------------------------+--------------+-----------------+------------+-----------------------+

This should contain the tag, this what incus-compose does:

❯ INCUS_REMOTE=ict-daily incus --project=incus-compose-cache image list
+----------------------------------------------------------------------------+--------------+--------+-----------------------------------------------------------------------------------------------------+--------------+-----------+-----------+-----------------------+
|                                   ALIAS                                    | FINGERPRINT  | PUBLIC |                                             DESCRIPTION                                             | ARCHITECTURE |   TYPE    |   SIZE    |      UPLOAD DATE      |
+----------------------------------------------------------------------------+--------------+--------+-----------------------------------------------------------------------------------------------------+--------------+-----------+-----------+-----------------------+
| ghcr.io/jochumdev/coredns-incus-plugin/coredns:latest                      | 23fee6a2bf71 | no     | ghcr.io/jochumdev/coredns-incus-plugin/coredns:latest (built by incus-compose)                      | x86_64       | CONTAINER | 22.92MiB  | 2026/08/10 18:46 CEST |
+----------------------------------------------------------------------------+--------------+--------+-----------------------------------------------------------------------------------------------------+--------------+-----------+-----------+-----------------------+

I presume that’s incus-compose’s specific functionality; in general, images which were downloaded and cached don’t have any alias in the local image store, and the description doesn’t include the tag.

$ incus launch -e --console oci-docker:hello-world:latest hello

...
$ incus image list
+-------+--------------+--------+----------------------------------------+--------------+-----------+-----------+----------------------+
| ALIAS | FINGERPRINT  | PUBLIC |              DESCRIPTION               | ARCHITECTURE |   TYPE    |   SIZE    |     UPLOAD DATE      |
+-------+--------------+--------+----------------------------------------+--------------+-----------+-----------+----------------------+
|       | 6ed7cb611f4d | no     | docker.io/library/hello-world (OCI)    | x86_64       | CONTAINER | 0.00MiB   | 2026/08/11 12:11 UTC |
+-------+--------------+--------+----------------------------------------+--------------+-----------+-----------+----------------------+

The issue I see with including the tag in the description is that in principle, multiple tags could point to the same image. If you launched the same image using more than one tag, presumably the description would only show the first one (the one which caused the image to be downloaded the first time).

Furthermore, tags can shift. That is, if you launched hello-world:latest last week, and then launched hello-world:latest this week, and the image has changed, then you could have two different cached images both described as hello-world:latest

I’m not saying it’s a bad idea though. Just that users need to beware that any tag shown in the description represents the state at the time the image was downloaded, and may have changed.

Yes incus-compose saves tags in description and alias.

Posted it as example.

About your issue, it is real and a big problem, this is why incus compose does per tag locking on a custom volume.

I have created tracking issues: