Velo Workspaces
What a virtual machine is
A virtual machine is a complete, isolated computer running as software inside another one. It isn't a sandboxed process, a chroot, or a container sharing the host's kernel. A VM boots its own kernel, manages its own memory, and doesn't know it isn't running on real hardware. The software that makes this possible, the hypervisor, sits between the guest operating system and the physical CPU. It steps in for the few privileged operations a guest can't be trusted to do directly, like touching physical memory it doesn't own or talking to real devices, and lets everything else run at full speed.
That last part is the whole point, and it's what people most often get wrong.
Hardware virtualization, not emulation
These two get mixed up constantly, and the difference decides performance:
- Emulation translates every instruction from one CPU architecture to another in software. An x86 emulator on ARM has to decode and re-implement x86 instructions as it goes. It can run anything, and it's slow, because every instruction pays for translation.
- Hardware virtualization runs the guest's instructions directly on the real CPU at native speed, and only hands control to the hypervisor for the small set of operations that need arbitration: memory mapping, interrupts, device access. Guest and host share an architecture, and the CPU has dedicated circuitry for keeping them apart.
A Linux VM on an Apple silicon Mac is the second kind: arm64 guest, arm64 host, arm64 silicon, and no instruction translation for the VM itself. Rosetta is a separate, narrower thing on top, for running x86-64 binaries inside an arm64 Linux guest. It's not what makes the VM work.
What the Virtualization framework gives you
Apple's Virtualization framework is the high-level API for creating and running VMs on a Mac, and the layer Velo Workspaces and most other Mac VM apps are built on. A VZVirtualMachineConfiguration declares what a VM gets: CPUs and memory, a boot loader, and a list of devices. Those devices follow the VIRTIO specification, a standard set of paravirtualized interfaces for network, storage, sockets, console, entropy and memory ballooning, so the guest talks to an efficient purpose-built interface instead of a pretend copy of some real piece of hardware. How Virtualization.framework works goes through the devices one by one, and the performance deep dive explains why paravirtualization is fast and where it isn't the whole story.
Linux guests and macOS guests aren't the same deal
The framework supports two kinds of guests, with different rules:
| Linux guest | macOS guest | |
|---|---|---|
| Runs on | Apple silicon and Intel Macs | Apple silicon Macs only |
| Where the system comes from | An official cloud image or installer ISO | Apple's official restore image (IPSW) |
| x86-64 binaries | Rosetta for Linux, if the guest opts in | Rosetta 2 as on any Mac |
| Graphics | Paravirtualized virtio-gpu, no GPU access | Metal-accelerated |
The last row surprises people. A macOS guest gets hardware-accelerated graphics through the framework's Mac-specific graphics device; a Linux guest doesn't. More on why below, and in what a macOS guest gets that a Linux one doesn't.
CPU and memory: assisted by hardware
Underneath, Apple's Hypervisor framework gives the Virtualization framework ARM's virtualization extensions: a dedicated CPU exception level for the hypervisor (EL2), and a second stage of memory translation, so the guest manages its own page tables while the host still controls which physical memory it can touch. None of that is simulated in software. The ARM virtualization deep dive explains why it costs less than you'd expect, with numbers.
Where the GPU story differs, and why AI Bridge exists
This is the one limitation to know up front. The framework gives a Linux guest virtio-gpu, a paravirtualized display with no path to the Mac's GPU, which Apple's own container team has confirmed in a public discussion. It's a platform limit, not a bug: there's no standard yet for sharing a GPU between host and guest this way on Apple silicon. If you want GPU compute directly inside a Linux VM, you can't have it.
That's why AI Bridge works the way it does. The model server stays on the Mac, on the real GPU, and the guest reaches it over a lightweight virtual socket instead. See the full architecture and the complete guide to running AI agents this way.
Where VM overhead comes from
Four places: CPU traps, memory translation, interrupt delivery, and device I/O. Apple silicon's virtualization extensions make the first three cheap by design, with a dedicated exception level, two-stage translation cached in the TLB, and hardware-assisted interrupts. The fourth, I/O, is where paravirtualization's trade-offs show up. That's measured, not asserted, in the performance deep dive and the inference benchmark.
When a VM is the right tool
A VM makes sense when you need a separate kernel: a different operating system, a security boundary that a shared-kernel container can't give you, or a clean environment you can throw away and recreate exactly. It's the wrong tool when a container will do. If the workload only needs its dependencies isolated on the same Linux kernel, a container starts faster and uses less memory. Do you need a VM, or is a container enough? covers where Docker Desktop, OrbStack and a disposable VM each sit.
Related reading: what determines VM performance on ARM, the architecture behind AI Bridge, and the modern local development stack on Apple Silicon, a map of everything else on this blog. Or download Velo Workspaces and try it yourself.