Virtualisation on Apple silicon Macs: 9 Monterey’s limitations

As my own experience of lightweight virtualisation on Apple silicon Macs grows, so does my understanding of its limitations when using macOS Monterey as either guest or host. If Apple follows its recent update cycles, Monterey 12.5 is likely to be the last ‘minor’ update before the release of Ventura, and from here on, it will probably only receive urgent major general bug fixes and security updates, and no feature enhancements. If that’s correct, the state of lightweight virtualisation with Monterey is now as good as it’s likely to get. This article highlights its most significant shortcomings.

No GUI Linux at all

Support for Linux guests in the Virtualization framework in Monterey is limited to command-line only. Virtio devices such as the Linux ‘scanout’ display aren’t available. Although heavyweight virtualisers such as Parallels and UTM may support GUI Linux guests, those based entirely on the Virtualization framework can’t: for GUI Linux guests, you’ll need a Ventura host.

No Windows for ARM at all

Microsoft doesn’t offer Windows for ARM as a product, only through its Insider Preview programme, or bundled with hardware. One of the clearly stated requirements of that programme is that a fully licensed copy of Microsoft Windows is already installed on that system, which Apple silicon Macs can’t comply with. Even if Microsoft were to offer licences for sale, as Windows doesn’t support the Virtio device standard on which lightweight virtualisation relies, a great deal of development would have to be performed before Windows for ARM could supported.

No Rosetta 2 for Linux

The availability of Rosetta 2 x86_64 code translation within Linux guests is limited to Ventura hosts, and not available in Monterey. However, Rosetta 2 is fully available in macOS Monterey guests regardless of the host. If you need to run x86_64 code in a Linux VM, then your host must be running Ventura.

No Apple ID access

For many potential users, the biggest limitation with macOS running in a VM is its inability to log into your Apple ID. This prevents access to the App Store, blocks the use of all paid-for and third-party App Store apps, rules out all iCloud and iCloud Drive access, and more.

There are workarounds for iCloud and iCloud Drive access, including logging into your account via, and relying on access provided by the host. Fortunately, most shared services, such as address book and calendars, aren’t really that important for the guest macOS.

Apple’s licence grants the use of virtualised macOS for four specific purposes:

  • software development;
  • testing during software development;
  • using macOS Server;
  • personal, non-commercial use.

For the first two, the inability to connect to iCloud is a serious limitation; the third purpose ceased to be meaningful when Apple discontinued its Server product back in April, and the final purpose could well be heavily dependent on paid-for and third-party App Store apps.

One of the most compelling uses of lightweight virtualisation is to enable us to run older apps that are incompatible with more recent macOS. When the host is running macOS 16, I’m sure there will be apps that ran in 12 but can’t cope with later versions of macOS. However, if those apps were delivered through the App Store, they can’t be run on a Monterey guest, even if Apple decides to support Apple ID access in Ventura or later. Bizarrely, Apple has put the apps it sells – its own, and those of third-party developers – at a major disadvantage in lightweight VMs.

At first I suspected that signing in with an Apple ID was restricted to virtualisers which had been granted the entitlement for a Bridged Network Device, but that isn’t the case. The fallback explanation became a requirement for access to the Secure Enclave, but that doesn’t apply to guest macOS virtualised on Intel Macs. It appears that this is a limitation entirely of Apple’s own making, and could in future be addressed by a suitable authentication service, which almost certainly won’t be accessible from Monterey guests.

No shared folders

I’ve so far been unable to share folders between the file systems of the guest and host, despite them being documented as available in macOS 12. I notice that this remains a stated limitation of Parallels Desktop version 18, which has only been released this week, and in VirtualBuddy.

One explanation for this is that mounting shared folders by the guest requires support for virtiofs. That’s currently not available in Monterey, so even when that version of macOS is the guest on Ventura, it appears impossible to mount any shared folders.

Again, there are workarounds. Enabling file sharing on the host, then connecting to that share from the guest using SMB works well, but is considerably slower. Convenient solutions such as AirDrop and iCloud Drive aren’t available because of the block on Apple ID access.

No non-standard devices

Lightweight virtualisation is completely reliant on the suites of Virtio and custom devices built into both the host and guest operating systems, but that also limits its support to those devices alone. This means that, as a guest operating system, Monterey will be limited to the devices it has at present, which excludes arbitrary external storage, optical drives, webcams, and other USB devices. In the future, lightweight virtualisation may preserve access to older software, but not to older hardware.

One issue of particular relevance to Linux guests is that the VM can’t access external file systems such as Btrfs except through sharing in the host macOS. Unless the host macOS has support for that external file system, and can share it, the guest will be unable to access it.

Clipboard, trackpad limitations

Other devices also currently have limited or absent support for Monterey guests. There’s no specific support at present for trackpads, although the mouse device works well unless you want to use gestures, which require a more advanced trackpad device only available in Ventura hosts. Spice clipboard support is less clear: that may yet come to work with Monterey.


With Ventura due for release this autumn/fall, probably in October, most of those limitations fall away, at least for Ventura guests running on Ventura hosts. Then the greatest remaining shortcoming will be lack of support for Apple ID features, which Apple may yet decide to address in any case. Sadly, most will come too late for Monterey guests, which are likely to be seen as Apple’s dress rehearsal for full virtualisation, not its opening performance. In a few years time I fear we’ll look back at Monterey as being only half a guest operating system.


Apple’s account of the Virtualisation framework
Parallels’ details of limitations to Desktop 18
VMware Fusion has no plans for virtualising macOS on Apple silicon Macs
This series: 6 Support limits
This series: 8 How Apple limits VMs