If you’ve experimented with lightweight virtualisation of macOS on an Apple silicon Mac, you may have tried a couple of tests, to see how many virtual machines (VMs) it can run simultaneously, and whether they can be nested to run a macOS guest inside a macOS VM. Even with the full might of a Studio M1 Ultra and 128 GB of memory, you’ll have discovered that you can only run two macOS guests at once, and they can’t be nested.

Nesting is an issue of more theoretical than practical importance. Although it’s a little disappointing that it doesn’t work at present, I don’t see anyone losing sleep over that, and can’t envisage it constraining what we can do with lightweight virtualisation. The limit on the number of macOS guests is more significant, though.

The moment that you try to run a third macOS guest, the Virtualization framework returns an error and fails to start it, with a VZErrorDomain Code of 6, interpreted as “The maximum supported number of active virtual machines has been reached.” That doesn’t appear to be a hardware limit, as an Ultra chip can afford to give each of the VMs 4 vCPUs and 8 GB of memory and still have plenty to spare for the host. It’s an arbitrary limit imposed by Apple’s licence agreement for macOS, which goes right back to Mac OS X Lion in 2011, if not before.

In case you don’t recall the exact wording of Apple’s licence agreement for Monterey, it imposes stringent limits on the number of copies of macOS that you can run. A full listing of those licences for macOS is here, and that for Monterey is available from here as a PDF. The licence for Ventura has yet to be published, of course.

The key section of the licence, 2B (iii), permits the user “to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.”

The list of purposes there is interesting, as it still refers to macOS Server, a product discontinued by Apple on 21 April 2022, and hardly something you’d want to run in a VM on an Apple silicon Mac. The last item (d) in that list also appears to exclude the use of macOS guests in corporate or commercial environments, which could have more serious implications, though.

As my lightweight Linux virtualiser hasn’t yet reached the point at which I can run multiple Linux VMs concurrently, I can’t confirm my suspicion that Apple’s Virtualization framework lets you run as many Linux VMs as you want, and your Mac can accommodate. I’ll be profoundly disappointed, though, if your favourite M1 Ultra is limited to running no more than two Linux VMs.

Eleven years ago, when Mac OS X Lion was king, running two Mac OS X guests side-by-side must have been quite an achievement, even on an 8-core Mac Pro. I’m sure those terms seemed perfectly reasonable at that time. Now that Apple has made lightweight virtualisation so straightforward, and many of us have notebooks with ten powerful ARM cores, let alone a Mac Studio with twice that number, it’s surely time for Apple to update its licence and unfetter the number and purpose of macOS VMs.

At the end of his presentation demonstrating the ease of coding virtualisation at WWDC 2022, Benjamin Poulain, speaking on behalf of Apple’s virtualisation team, remarked that “we cannot wait to see what you will do next with this technology”. For a start, it would help if Apple were to let us run as many instances of macOS as our Mac hardware allows, and for purposes beyond software development and personal non-commercial use.

Until Apple updates its macOS licences to let us get the most out of virtualisation, I fear that Apple’s virtualisation team could be disappointed at what we will do next with technology being strangled by licence terms from eleven years ago.

Postscript

It may help understanding if I explain how licensing works with virtualisation (drawing attention to the fact that I’m not a lawyer, of course).

I have written and made publicly available a virtualisation app, Viable. In doing so, I haven’t entered into any licence agreement with Apple, although Viable runs macOS in its VMs. If I had the talent, knowledge and time, I could create an app which, instead of using the macOS Virtualization framework, did it all through Hypervisor framework instead. That doesn’t and can’t impose limits on the number of VMs running at any time, nor the operating systems that it can run as guests.

Instead, the licence to run macOS as a guest is Apple’s, with you as the end user. As your licence from Apple explicitly limits you to running no more that two copies of macOS as guests, it’s up to you to observe that licence condition, and up to Apple to enforce it on you. So, in the past, you may well have run more than two copies of macOS in VMs, although that’s in breach of Apple’s licence.

What’s different with lightweight virtualisation using the Virtualization framework in macOS is that it’s Apple’s code which creates and runs each VM, thus Apple can enforce its restrictive licence terms by limiting the number of macOS VMs that can be run at any one time, and that’s what it does, and why I think Apple needs to change that.

(I’m grateful to Eric for reminding me of the limit in Apple’s licences.)