Before Apple silicon Macs, you’ve been able to run different versions of macOS, Linux or Windows in third-party virtualisers, such as those from VMware and Parallels. Those products enable a virtual machine running a different operating system to be hosted in macOS, both running code for Intel processors. As part of its engineering preparations for the switch to using Arm processors, Apple decided that the only practical way to support virtualisation on its new Mac hardware was to build it into macOS. This was to enable older versions of macOS, and other operating systems including Linux and Windows for Arm, to run in virtual machines.

This is quite different from the more challenging problem of running operating systems for different processors, such as Intel, on Apple silicon Macs. Although Intel apps can have their code translated by Rosetta 2, that doesn’t work for operating systems, which need a software emulator, a feature left for the likes of UTM.

Hypervisor

The fundamental requirement for modern virtualisers hosted on a primary operating system like macOS is a hypervisor, which Apple added to macOS back in OS X 10.10, in 2014. Like Intel processors, Arm CPUs provide hardware support for hypervisors, so much of the remaining work to implement virtualisation in Apple silicon Macs centred on device support. That had been relatively straightforward for Intel Macs, as they mainly use PC hardware components, but that isn’t the case for Apple’s new Macs.

Virtio drivers

Every single hardware device in an Apple silicon chip is different from its equivalent (if there is one) in Intel Macs. Even if Apple had wanted to document them fully for external use, the engineering effort to match device support in Intel Macs would have been too costly for any third party. Thus starting with a hypervisor and expecting others to build a complete virtualiser wasn’t feasible, nor was it likely to result in the high performance that Apple and users expected. What Apple did instead was to build device support into macOS, in the form of Virtio drivers.

Virtio is a standard originally developed by Rusty Russell to provide an abstraction layer over I/O devices. When the guest operating system calls to open a file, for example, that’s passed to a front-end Virtio storage device para-driver, and from there into a Virtio back-end driver that interacts with the storage device. Although this might seem less efficient than traditional virtualisation, in practice it can prove far more efficient.

Its most obvious advantage is that creating a virtualiser app becomes a matter of configuring and opening the required Virtio devices, and letting the guest, Virtio and the host get on with it. And that’s essentially what an app does with Apple’s Virtualisation framework.

Apple’s choice of Virtio was undoubtedly swayed by the fact that Linux already has good Virtio support, but at the time macOS had none. In the couple of years preceding the release of Monterey, Apple’s engineers thus set about building Virtio support into macOS, which explains why macOS lightweight virtualisation is only available in Monterey and later hosts, and when running Monterey and later guests. As implemented in macOS (both as guest and host), there are also extensions to support keyboard and pointing devices, a shared clipboard, and high-performance graphics with Metal and GPU support.

In the Virtio model, providing such support is the task of the operating system, not the virtualiser. For vendors like VMware and Parallels this reduces not only the cost of development, but also the commercial value of their products; there’s no scope for either of them to engineer better or faster graphics support, as that’s determined by features provided in both guest and host operating systems, via Virtio or an equivalent. That puts Apple in charge of what hardware and features are supported by virtualisation on Apple silicon.

Performance

On the other hand, it guarantees optimum performance in VMs. Not only is their CPU and GPU code run direct on the hardware, just as in the host, but Virtio devices deliver almost as good performance as on the host. Comparable Geekbench 6.3.0 benchmarks when running macOS Monterey as both guest and host are:

• CPU single core VM 3,643, host 3,892
• CPU multi-core VM 12,454, host 22,706 (limited by the number of cores available)
• GPU Metal VM 102,282, host 110,960, with the VM as an Apple Paravirtual device.

Subsequent versions of macOS have improved on those. It’s worth noting that virtual cores allocated to a VM are primarily Performance cores, so threads running in the VM that would normally be run on Efficiency cores normally run significantly faster than they would do in the host.

Initially, performance of VM primary storage in its disk image wasn’t good, but more recently this has improved substantially, even with FileVault enabled in the VM.

Rosetta 2

Although it can’t be used to translate a guest operating system, Rosetta 2 can still be used inside a macOS VM to translate and run 64-bit Intel code in apps that are compatible with macOS 10.15 Catalina, but is subject to the same limitations as any version of macOS on Apple silicon, in that it can’t handle older or 32-bit apps. This will become most useful when Apple drops full support for Rosetta in macOS 28. VMs with older versions of macOS will still be able to translate and run compatible 64-bit Intel code, even though the host won’t be able to.

Major limitations

Support for iCloud and iCloud Drive access wasn’t made available in VMs until Sequoia, and now requires that both the guest and host must be running macOS 15.0 or later. As VMs that support these features are structurally different from earlier VMs, this also means those VMs that have been upgraded from an earlier macOS still can’t support iCloud or iCloud Drive.

The greatest remaining limitation in virtualising macOS on Apple silicon is its inability to run many apps from the App Store. Although some do run without problems, any that check their App Store credentials will fail, as a VM can’t be signed into the App Store. This appears to be the result of Apple’s authorisation restrictions, and unless Apple rethinks and reengineers its store policies, it looks unlikely to change.

Some lesser features remain problems. For example, network connections from a VM are always treated as being Ethernet, and there’s no support for them as Wi-Fi, even though they can connect using the host’s Wi-Fi. Audio also remains odd, and appears to be only partially supported. Although Sequoia has enabled support for storage devices, earlier macOS was confined to the VM’s disk image and shared folders.

Many aren’t aware that Apple’s macOS licences do cover its use in VMs, in Section 2B(iii), where there’s a limit of two macOS VMs that can be running on a Mac at any time. This is enforced by macOS, and trying to launch a third will be blocked. For the record, the licence also limits the purposes of virtualisation to “(a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.” It’s worth noting that Apple discontinued macOS Server on 21 April 2022, and it’s unsupported for any macOS more recent than Monterey.

Usage

Some examples of what you can use a macOS VM for:

• run apps compatible with Sonoma but not Sequoia, on M4 and M5 Macs that can’t run Sonoma;
• run apps in a custom environment, e.g. with different region and language settings;
• check and access potentially malicious documents or apps in a locked-down environment;
• test compatibility with multiple versions and localisations of macOS;
• work with highly sensitive data, in an isolated environment;
• access a different iCloud account simultaneously;
• run beta-test versions of macOS 27.

Summary

macOS VMs on Apple silicon can:

• run Monterey and later on any model, but not Big Sur or Intel macOS;
• run most betas of the next release of macOS;
• run Intel apps using Rosetta 2;
• deliver near-normal CPU and GPU performance, and support FileVault;
• access iCloud and iCloud Drive only when both host and guest are running Sequoia or later;
• but they can’t run most App Store apps.