ketchalegend
← Back

How small can a macOS VM get? Performance findings

An experiment reducing macOS VM resources from 4 cores/8GB to 2 cores/4GB shows surprisingly good performance, with memory usage scaling down with cores.

A macOS VM running at 2 cores and 4 GB felt perfectly brisk. I didn't believe it either. But Howard Oakley's experiment systematically reduced resources—cores and RAM—to find the sweet spot where a macOS VM remains usable. Spoiler: it can go surprisingly low.

macOS VM Performance Scaling: From 4 Cores to 2

Using Apple's Virtualization framework (VZ), Oakley started with 4 virtual cores and 8 GB of vRAM, stepped down to 3 cores/6 GB, then 2 cores/4 GB. The VM stayed usable at every tier, with memory usage falling to 3.1 GB at the lowest spec. His key finding: memory tied to each core means cutting cores also trims memory overhead.

Hacker News Reactions and Insights on macOS VM Resources

The post resonated because macOS VMs are a pain point. One commenter wrote: "My only experience with VMs on macOS is colima+docker, and it's relatively painful and inefficient (but usable)." Another pointed out that if you allocate 8 GB but the VM uses only 5 GB at startup, launching applications later may demand the full allocation—so you can't go too low. But there's also a contrarian view: "The first iPhones only had 128 MiB of RAM and they ran a trimmed down version of macOS Tiger... it's definitely possible [to go lower], and probably not that hard either."

Practical Takeaways for macOS VM Provisioning

The conventional wisdom says you need at least 4 GB and 2 cores. This experiment suggests 4 GB is a generous minimum for lightweight workloads. macOS's memory pressure algorithm scales with available memory—fewer cores means less background work, so the OS self-trims. That's elegant, but it also means you can't just throw in more apps later without hitting swap.

The experiment ran actual tasks (Safari, Mail, Xcode) instead of synthetic benchmarks. That's the right approach for answering "is this usable?" For headless server tasks like CI builds, you might go even lower by not attaching a graphics device, which avoids WindowServer overhead.

Building a Minimal macOS VM with Apple Virtualization Framework

Here's a minimal headless VM in Swift using VZ. Notice the VZMacOSBootLoader and no graphics device:

let config = VZVirtualMachineConfiguration()
config.cpuCount = 2
config.memorySize = 4 * 1024 * 1024 * 1024  // 4 GB
config.bootLoader = VZMacOSBootLoader()

let storage = try VZDiskImageStorageDeviceAttachment(url: diskURL, readOnly: false)
config.storageDevices = [VZVirtioBlockDeviceConfiguration(attachment: storage)]

let network = VZVirtioNetworkDeviceConfiguration()
network.attachment = VZNATNetworkDeviceAttachment()
config.networkDevices = [network]

let vm = VZVirtualMachine(configuration: config)
try vm.start()

When to Cut Down Your macOS VM Specs

  • Lightweight tasks: Start at 2 cores/4 GB. For a browser and terminal, it's plenty. Memory-wise, 4 GB leaves ~900 MB free for file cache.
  • Watch allocation: Allocating more RAM doesn't waste it—the OS uses it for cache. But over-allocation may cause host swapping. Monitor with memory_pressure or Activity Monitor.
  • Consider headless macOS: For server workloads (e.g., xcodebuild or swift test), avoid the graphics device to trim memory. Tools like Tart let you script VM creation with CPU/memory overrides.
  • Benchmark your workload: Use hyperfine or time to measure build times at each resource tier. The difference between 2 and 4 cores might be small if your build is I/O-limited.

Verdict: Test Your Workload, Don't Guess

If you're a macOS developer or maintain CI runners for Apple platforms, saving 2 cores and 4 GB per VM means more VMs on the same hardware or cheaper Mac minis. For casual testing, low-end specs work fine. The experiment is a wake-up call: we often over-provision out of habit. Measure instead of assuming. Go try 2 cores/4 GB and see if it hurts. I bet it won't.

Originally posted on Hacker News Apple Virtualization Framework docs