Fundamentals

Can You Install x86 Linux on an Apple Silicon Mac?

A direct answer to a question this blog's other posts have each covered a piece of: no, not as a full guest operating system, through Virtualization.framework — which is what Velo Workspaces and every other native Mac virtualization app on Apple Silicon actually uses. That's not a current gap someone hasn't gotten around to fixing. Here's why, what can actually do it, and why the thing you're trying to accomplish very often doesn't need it in the first place.

The direct answer

Virtualization.framework — Apple's own hypervisor API, and the one this blog's VM posts are all built on — only ever runs a guest built for the same CPU architecture as the host. On an Apple Silicon Mac, that means arm64 guests, full stop. There's no x86_64 Linux entry anywhere in it, by design, not as an oversight: the framework-vs-QEMU comparison covers exactly why, in the "emulation reach" section — it comes down to what the two tools were built to do in the first place, not which one Apple or the QEMU project simply hasn't finished.

What can actually do it

QEMU can — specifically its TCG (Tiny Code Generator) mode, which translates an entire different architecture's instructions into the host's, in software, one guest instruction at a time. That's a genuinely different capability from anything Virtualization.framework offers, and it's why QEMU (directly, or through a friendlier front end like UTM) is the actual answer if a real x86_64 Linux installation is what's needed. The tradeoff is real too: none of that translation is hardware-accelerated the way an arm64 guest is on Apple Silicon, so expect noticeably slower performance than anything in this blog's own Virtualization.framework benchmarks — full software CPU emulation, not paravirtualized acceleration.

Before reaching for that: what do you actually need?

In practice, "I need x86 Linux" is very often standing in for a narrower problem that has a faster answer:

"I need to run one x86_64 program" — that's Rosetta for Linux, translating that specific binary inside a native, fully-accelerated arm64 guest. Meaningfully faster than emulating an entire OS to run one executable.
"I need to run an x86_64 Docker image" — that's a container-runtime problem, not a guest-OS problem, and has its own answer, including one that can piggyback on the same mechanism as Rosetta for Linux.
"I need a package that isn't built for arm64" — check first whether it's genuinely missing or just not yet mirrored; the Ubuntu post's Rosetta section covers this gap concretely, including where a straight package install just 404s.
"I need to test on a CPU architecture my users actually run" — that's the one case Rosetta genuinely can't stand in for, because it's about verifying architecture-specific behavior, not working around a missing binary. That's where QEMU's full emulation, or better, an actual x86_64 host somewhere, is the right tool.

The practical takeaway

Default to a native arm64 Linux guest through Velo — Ubuntu, Debian, Fedora, and the rest of this blog's distro coverage all boot fully accelerated that way — and reach for Rosetta when a specific x86_64 binary is the actual blocker. Reach for QEMU-based full emulation only once it's clear the requirement really is "a genuinely different CPU architecture," not "one program that happens to have been built for one."

Related reading: Virtualization.framework vs. QEMU for the full architectural comparison, Rosetta 2 in Linux VMs for the binary-translation mechanism, and ARM64 vs. x86-64 on Apple Silicon for how this all fits together with macOS apps and containers. Or download Velo Workspaces and try it yourself.