An Apple silicon host, no way around it

A macOS guest needs an Apple silicon Mac. On an Intel Mac, Linux guests work fine but macOS guests aren't available at all. That line is drawn by Apple's Virtualization framework, not by Velo Workspaces.

One image: the latest macOS for this Mac

Linux means choosing a distribution and a release. macOS doesn't: choose Installer image, pick macOS, and Velo Workspaces asks Apple's restore-image service for the latest macOS this Mac supports. There's no list of older releases to browse. If you need a specific build, Choose File… accepts an .ipsw restore image you've downloaded yourself.

Restore images are large, typically 15 to 18 GB. Since 1.2 the download stays in Settings › Images, so a second macOS workspace installs from the copy you already have instead of fetching it again. The install itself is unattended: Apple's installer runs by itself, and you finish macOS's setup assistant in the workspace's window.

The GPU story is the opposite of Linux

A Linux guest gets virtio-gpu, a paravirtualized display with no path to the Mac's GPU, which is why AI Bridge exists for AI inference. A macOS guest doesn't hit that wall. Apple's platform gives it a Metal-backed graphics device built to deliver near-native GPU performance through the Metal API. The limitation that shapes every Linux post on this blog, including the Parallels and UTM comparison, doesn't apply here.

Input feels native for a related reason. A macOS guest gets real trackpad and keyboard passthrough with multi-touch gestures (two-finger scroll, pinch to zoom, Mission Control swipes), not just forwarded clicks and keystrokes. Together with the graphics, it feels like using another Mac, which a Linux console never tries to.

Shared folders, no mount command

Linux workspaces need a mount -t virtiofs command for each shared folder. macOS guests don't: every shared folder appears under /Volumes/My Shared Files/ as soon as the guest boots. The caveat is that this relies on macOS 13 or later inside the guest. An older macOS guest doesn't recognize the mechanism and silently mounts nothing.

The gotcha: the disk isn't the whole workspace

A macOS guest's hardware model, machine identifier and auxiliary boot storage are kept beside its disk image, in a small metadata folder that belongs to the workspace. Copy or move only the disk file, to back it up or share it by hand, and you get a workspace that can't start, because the platform data it needs to boot isn't there. Move macOS workspaces with the app, or keep the whole bundle together.

What stays on the Linux side

Rosetta needs no setup here. The VirtioFS share and binfmt registration described in the Ubuntu, Debian and Fedora posts are for Linux guests. A macOS guest is an ordinary macOS installation, so an x86-64 Mac app triggers Rosetta 2 the usual way, exactly as on a real Mac.

AI Bridge is for Linux guests. A macOS guest doesn't need it, for the same reason: it already has GPU access of its own.

The built-in SSH terminal is for Linux workspaces too. To reach a macOS guest over SSH, turn on Remote Login inside it and connect the way you would to any Mac.

Related reading: the Linux side of this, starting with Ubuntu on Apple Silicon; the architecture behind AI Bridge and why it's Linux-only; how the GPU story compares with other VM apps; and, if you save a macOS guest as a base image, a naming convention worth using. Or download Velo Workspaces and try it yourself.