[Bug]: Can't run amd64 container machine on Apple Silicon

[wmanth]

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

Steps to reproduce

Follow the chapter Bring your own container machine image of container machine documentation with --arch amd64 as parameter:

container build --arch amd64 -t local/ubuntu-machine:latest .
container machine create local/ubuntu-machine:latest --arch amd64 --name ubuntu

Run a command on that machine:

container machine run -n ubuntu uname -a

Problem description

Expected Behavior

The machine information is printed on command line as is with container run local/ubuntu-machine:latest, e.g.:

$ container run --arch amd64 --rm local/ubuntu-machine:amd64 uname -a
Linux 9f6949cd-c2d0-4c47-af46-1b13a33a970e 6.12.28 #1 SMP Tue May 20 15:19:05 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Seen Behaviour

Instead it reports an error:

$ container machine run -n ubuntu uname -a
Error: failed to exec [/sbin.machine/init -s uname] Error Domain=NSPOSIXErrorDomain Code=8 "Exec format error"
Error: failed to start process 66c65e9c-3ae1-429a-9fd0-7c61ad5d0134 in container ubuntu-87d6d8 (cause: "internalError: "failed to start process (cause: "internalError: "startProcess: failed to start process: internalError: "vmexec error: internalError: "failed to exec [/sbin.machine/init -s uname] Error Domain=NSPOSIXErrorDomain Code=8 "Exec format error""""")"")

Environment

- OS: macOS 26.5.1 (25F80)
- Xcode: 26.6 (17F113)
- Container: Container CLI version 1.0.0

Code of Conduct

• I agree to follow this project's Code of Conduct

[iamvirul]

Found the root cause :

MachinesService.boot() calls ClientKernel.getDefaultKernel(for: .current) when no custom kernel path is set. On Apple Silicon, .current resolves to .linuxArm, so AMD64 machines boot with the default-arm64 kernel instead of default-amd64.

[wmanth]

@iamvirul What additional steps did you take to get the amd64 machine working?

After compiling the PR version, first I was confronted with:

Error: failed to boot container machine (cause: "notFound: "default kernel not configured for architecture amd64, please use the `container system kernel set` command to configure it"")

Claude helped me figuring out I had to set the amd64 kernel by calling:

container system kernel set --arch amd64 --tar https://github.com/kata-containers/kata-containers/releases/download/3.28.0/kata-static-3.28.0-amd64.tar.zst --binary opt/kata/share/kata-containers/vmlinux-6.18.15-186 --force

After that, I ended up with:

Error: failed to boot container machine (cause: "internalError: "failed to create container (cause: "unsupported: "platform linux/amd64"")"")

After deeper analysis, Claude summarized it like this:

The container machine create --no-boot succeeded, confirming the image and kernel are fine. The failure happens during boot because the init filesystem image (ghcr.io/apple/containerization/vminit) does not have a linux/amd64 variant — it only ships linux/arm64.

This is a current limitation of the containerization framework. The vminit (the tiny init process that runs inside the VM to manage the container lifecycle) hasn't been built for amd64 yet.

Summary of what we accomplished:

• Installed the amd64 kernel from Kata Containers
• The machine was created successfully (--no-boot works)
• Boot fails because ghcr.io/apple/containerization/vminit:0.35.0 (the VM init image) doesn't provide a linux/amd64 build

What's blocking you:
The vminit image at ghcr.io/apple/containerization/vminit only publishes an arm64 variant. Until the apple/containerization project publishes a multi-arch vminit image that includes linux/amd64, booting an amd64 container machine on Apple Silicon isn't supported.

Potential workaround: If you can build a custom vminit for amd64, you could configure it via the [vminit] section in ~/.config/container/config.toml (or wherever your system config resides), pointing image to a local amd64-capable vminit image. However, building vminit from source for amd64 would require cross-compiling it from the containerization repository.