So I am also confused with architectures… 
I was convinced that since lxd has support for vms that I would be able to install images for other architectures. But can’t seem to find any info on how to do that. So here I am.
Is this possible at all?
Thanks.
Nope, LXD supports hosts of various architectures so you can have a cluster with LXD servers running on Intel and Arm for example which would then allow using a variety of architectures for your VMs but we are not in the business of simulating a foreign architecture (which then doesn’t allow using all of the nice virtio and paravirt features we rely on).
Ok, thanks. Though I understand the reasons I can’t help feeling sad… imagine running a x86 lxd vm on rpi… or having an rpi with x86 vm, and inside it a x86 docker container…
x86 on rpi would be so slow you really wouldn’t like it much 
We’ve been running full CPU emulation for some riscv64 builds and even using 32-core AMD Epyc CPUs we end up with an emulated target which feels about as fast as a rpi.
hehe I guess that’s true
We now have, on MacOS Ventura, the ability to run x86 code quickly on ARM via Rosetta. It would be really nice to be able to run an x86 LXC container on Apple Silicon.
I’ve tried this but get (as you might expect) Error: Failed creating instance record: Requested architecture isn’t supported by this host when I do an lxc launch.
If we assume that Rosetta allows us to run x86 code on linux, what would be required get LXD to permit this configuration?
The Rosetta stuff done by Apple works as a binfmt_misc hook. This is similar to the approach taken by qemu-user-static though quite a bit more performant.
That approach however doesn’t mean the kernel can natively execute the other architecture, instead a userspace binary is used to tunnel all the instructions through. This makes it unsuitable for containers.
We played with making this work with containers quite a few years ago, at the time trying to get arm containers running on intel. While this works for individual commands, running the entire init system and network components through that translation layer was causing a lot of issues and required a frankstein container where about half the binaries were of the native architecture and half of the foreign architecture.
If we were to modify LXD to detect the presence of Rosetta and allow running x86_64 containers in such a VM, /sbin/init would simply fail to execute, causing the container to die immediately.