Architecture error preventing instance creation & same configuration key cannot be found

Incus
1

Hi,

I am currently testing a small cluster with mainly aarch64 nodes, when I try to create an instance on a x86_64 node it shows this:

node3:~ # incus init --target node3 docker:caddy:2.10.2 --profile=Test
Creating the instance
Error: Failed instance creation: Failed creating instance record: Requested architecture isn’t supported by this host

I thought ‘architecture’ was a writable config option for an instance/container, but it doesn’t seem to be recognised by the launch/init subcommands.

node3:~ # incus init --target node3 docker:caddy:2.10.2 --profile=Test -c architecture=x86_64
Creating the instance
Error: Failed instance creation: Failed creating instance record: Unknown configuration key: architecture
node3:~ #

Also not sure if this issue would have been the other way around, if I was to have created the initial instance on a x86_64 node first, and then tried creating another using one of the aarch64 nodes (I wonder if it then would have prevented creating any instances using this image, on the aarch64 nodes).

The profile ‘Test’ used above just has a network assignment, and a config/option entry for 'architecture’, however the result is the same when the profile flag is omitted:

node3:~ # incus init --target node3 docker:caddy:2.10.2 -c architecture=x86_64
Creating the instance
Error: Failed instance creation: Failed creating instance record: Unknown configuration key: architecture
node3:~ # incus init --target node3 docker:caddy:2.10.2 
Creating the instance
Error: Failed instance creation: Failed creating instance record: Requested architecture isn't supported by this host
node3:~ #

I would like to have the same version of this Caddy image running on every node in the cluster, but there seems to be no way to do it.

I was hoping that just by specifying the location in the web UI during instance creation, it would know what architecture to pull based on the architecture for the chosen node.

Any input would be appreciated, thanks.

2

This would suggest that 2.10.2 doesn’t have an arm64 build available on the Docker Hub.

3

Hmm, no, looks correct on the Docker Hub. I think it’s an issue with our image caching mechanism…

Can you try deleting the cached image with incus image list and incus image delete see if that fixes it?

4

If that does the trick, then it’d be good to have an issue filed at Sign in to GitHub · GitHub so we can find a way to track an architecture specific fingerprint to avoid that issue.

5

That definitely did the trick, many thanks. After removing the cached image via the web UI:

node3:~ # incus init --target node3 docker:caddy:2.10.2 -c architecture=x86_64
Creating the instance
Retrieving image: Unpacking the OCI image
Retrieving image: Generating image metadata
Retrieving image: Generating rootfs tarball: 17.59MB (2.51MB/s)
Error: Failed instance creation: Failed creating instance record: Unknown configuration key: architecture
node3:~ # incus image list
±------±-------------±-------±------------------------------±-------------±----------±---------±----------------------+
| ALIAS | FINGERPRINT  | PUBLIC |          DESCRIPTION          | ARCHITECTURE |   TYPE    |   SIZE   |      UPLOAD DATE      |
±------±-------------±-------±------------------------------±-------------±----------±---------±----------------------+
|       | cef7fe17d4df | no     |  (OCI) | x86_64       | CONTAINER | 19.16MiB | 2025/11/21 16:55 SAST |
±------±-------------±-------±------------------------------±-------------±----------±---------±----------------------+
node3:~ # incus init --target node3 docker:caddy:2.10.2
Creating the instance
Instance name is: engaged-llama

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

node3:~ #
1 Like
6

Would be great if you could file an issue then so we can find a way to handle this cleanly. I run multi-architecture clusters with some OCI instances, but I’ve not yet had the case where I’m running the same OCI application on two different architectures so I didn’t hit that one myself.

7