No sooner had the pixels dried on yesterday’s article, about running a server on Monterey, than I was being told that I had disappointed by not recommending a Linux server, particularly for Apple silicon Macs. While some may find solace doing that, this article explains some of the obstacles you need to negotiate.

Boot into Linux

There’s only one way to boot an Apple silicon Mac into Linux, and that’s using Asahi Linux. This is currently available in alpha, and runs on several M1 and M2 models using its own bootloader, designed for dual-booting a Mac between Linux and macOS. There’s also support in OpenBSD, if you’d prefer.

What you then get is a full Linux distro, with support for almost all the hardware of your Apple silicon Mac. To learn how to set this up as a server, there’s ample Linux support material. As Asahi runs instead of macOS, Rosetta 2 isn’t available to translate x86 binaries, and only ARM native code can be run without the likes of QEMU.

Virtualise Linux in macOS

Of the two major commercial virtualisation products, only Parallels Desktop currently supports virtualising Linux on Apple silicon. Version 18 supports ARM versions of Ubuntu Linux, Fedora Workstation, Debian GNU/Linux, and Kali Linux. UTM supports a wider range of distros, but of course can still only virtualise those built for ARM processors. I don’t think that either Parallels or UTM currently support the use of Rosetta 2 to run x86 binaries within the VM, although that feature may be available when hosted on Ventura.

Ventura is also expected to bring several new and free lightweight virtualisation apps to run GUI Linux with Rosetta 2 support, among them my own Liviable, which has been working well in Ventura beta-releases. The same macOS framework also supports Linux from the command line in Monterey and later, although I’m not aware of any pre-built command tool that uses it, yet.

One major limitation of Linux VMs on Apple silicon is their inability to use core allocation strategies in the way that macOS does. Virtual CPUs (vCPU) are allocated for guest operating systems as if each vCPU was a thread running at high Quality of Service. There’s no way for the guest operating system to elect to run background services on E cores, for instance. This is shown in the example CPU History window from the host’s Activity Monitor below.

Here I’m running two Linux VMs, each allocated 3 vCPUs and 8 GB of memory, within macOS Ventura. Processes running in those VMs are being run on the 8 P cores, labelled as Cores 3 to 10, with some virtualisation and macOS support running on the lightly loaded E cores. Neither the VMs nor the user can transfer any of the VM processes to run on the E cores, except as overspill when the P cores approach maximum active residency. In effect, the 10-core M1 Pro is running as if it was little more than an 8-core SMP processor, like the Intel Xeon in my iMac Pro.

This is worse on a Mac using the original M1 chip, which has only 4 P cores. With no way of knowing which threads to run on which type of core, using 6 vCPUs for Linux VMs would end up running some of the processes in the VMs on the E cores, with much of the host macOS, which could have unexpected effects on performance.

This is an important difference between Linux VMs and booting an Apple silicon Mac in Asahi Linux, which gives full control over the use of the cores.

macOS services

There are some important services that can only be hosted on macOS. The most widely used of these, and irreplaceable for many, is the Content Caching server, which not only provides macOS and App Store updates, but also iCloud content to Macs and devices.

One advantage of virtualising your Linux server in macOS is that the host operating system can still support Content Caching, provided that sufficient core capacity and memory remain.

While backup storage, particularly that for Time Machine, is well supported on non-macOS systems using sparse bundles with SMB, backups over a network are susceptible to performance bottlenecks, and the first full backup can take several days unless the system has been carefully optimised.

Server restart

Relying on a virtualised Linux server makes it impractical for the server to restart automatically in the event of the Mac restarting. This may change with the availability of suitable command-line virtualisation, which could be configured to launch automatically after startup. But current virtualisation software is largely reliant on user interaction with GUI Linux distros. The only potential exception to this is UTM, through its underlying use of QEMU.

If your server is running headless, a start up or restart would require you to connect to the server from another system, log in, launch the virtualiser, then select and launch the VM before its services would become available again.

System administration

If, as the macOS kernel proclaims proudly, XNU is not Unix, then a Linux server isn’t macOS, not in the slightest. Even when managed using GUI utilities, Linux does things differently, and you’ll need to learn how to manage your server, and where to obtain information in the event of problems. For some Mac users this proves straightforward, but for others it just never works out.

Whatever you choose, I wish you success.