Native arm64, not an emulated PC

Ubuntu on an Apple Silicon Mac isn't x86 Ubuntu running slowly under emulation — it's Ubuntu's own arm64 build, running on the CPU's native instruction set, the same way Ubuntu runs on an AWS Graviton server or a Raspberry Pi. Canonical's 26.04 LTS release extended Livepatch's rebootless kernel patching to arm64 for the first time and shipped a generic arm64 desktop ISO aimed at exactly this kind of platform — VMs and Arm laptops — rather than treating arm64 as an afterthought. That's the upside: no emulation tax, and arm64 as a first-class target rather than a secondary build.

The downside is the flip side of the same fact: it's a genuinely different CPU architecture, not a compatibility mode. Anything precompiled for x86-64 — a binary-only tool, an old .deb with no arm64 build, a container image someone only ever published as amd64 — won't run without help. That's the category of problem worth understanding before you hit it, not a defect specific to any one app.

What "download an official image" actually saves you from

If you set this up by hand with a general-purpose tool, the official Ubuntu Server cloud image is a good starting point but not a finished one: it ships as a .img/qcow2-style file that Apple's Virtualization framework can't boot directly, so you convert it to raw format first. Then you still need cloud-init to actually configure the thing on first boot, which on Apple's virtualization stack means hand-wiring a NoCloud datasource and passing boot arguments like console=hvc0 root=/dev/vda ds=nocloud;s=http://<host>:8080/... so the guest can find its own seed data. None of that is hard exactly, but it's exactly the kind of multi-step, easy-to-get-subtly-wrong setup that's worth automating away rather than repeating by hand every time.

That's what Velo Workspaces' image picker is actually for: choose "download an official image," pick Ubuntu, and the app fetches the image directly from Ubuntu's own source and handles the conversion and first-boot configuration itself — you get a running, logged-in workspace rather than a qcow2 file and a checklist.

Server vs. Desktop, and the one networking gotcha worth knowing in advance

Ubuntu Server (minimized) is the common choice for a disposable dev or CI-style workspace — small, headless, fast to boot — and it's the image used as the example throughout this blog's own benchmarks. There's one specific, documented gotcha worth knowing about ahead of time rather than debugging cold: a workspace cloned from a saved Ubuntu Server (minimized) base image can come up without an IP address. The cause is mundane once you know it — every workspace gets a new, unique MAC address, including clones, but Ubuntu Server's minimized install configures networking with Netplan on top of systemd-networkd, which by default binds the network config to the base image's original MAC address rather than matching by interface name. Once the clone's MAC differs, nothing matches, and DHCP never gets requested. It's a one-line Netplan fix once you know to look for it — the full steps are in the support FAQ — but it's the kind of thing that looks like a mysterious clone-only bug if you don't know it's a known, specific interaction between Ubuntu's own networking defaults and cloning.

Running x86-64 binaries anyway: Rosetta, and its real limits

For the cases where you do need something that's only ever shipped for x86-64, Apple's Rosetta translation layer works inside a Linux guest too, not just for macOS apps — Velo Workspaces wires it in as a VirtioFS share plus a one-time binfmt registration, and the support FAQ has the exact steps (Ubuntu and Debian share the same update-binfmts tooling, so the Debian instructions apply directly).

Be realistic about what this actually fixes, though: Rosetta translates a single dynamically-linked x86-64 binary reasonably well, but it doesn't manufacture x86-64 packages that don't exist for arm64, and Ubuntu's own arm64 ports repository doesn't mirror every amd64 package — pulling in amd64 sources by hand can hit a plain 404 for packages that were never built for that combination. A binary with x86-64-only compiled dependencies, or one that needs a full amd64 package tree behind it, is a much rockier case than "translate this one executable." Good for the specific tool you're stuck needing; not a general-purpose way to pretend the CPU architecture doesn't matter.

Putting it together

A practical pattern: download the official Ubuntu Server image once, install and configure whatever your base setup actually needs — packages, dotfiles, Rosetta if you need it — then seal it as a base image so every future workspace clones from that known-good state in seconds instead of repeating setup. That's the same disposable-workspace pattern this blog has covered for QA and DevOps use specifically, and it's exactly the setup used in the MLX + AI agent setup guide and the inference benchmarks published here, both built on Ubuntu Server 26.04.

Related reading: Debian on Apple Silicon, including why Debian's networking defaults sidestep the clone gotcha above, and Fedora on Apple Silicon, next in this series, including a Rosetta mechanism that's genuinely different from the one above rather than just a different command; the disposable VM workflow for QA and DevOps; and why VMs on Apple Silicon perform the way they do architecturally. Or download Velo Workspaces and try it yourself.