Have you been able to update an existing lightweight macOS Virtual Machine on Apple silicon to Sequoia 15.4? So far, I’ve had three failures ending in kernel panics, and no successes. Maybe I’m holding it wrong?
Good news …
I’ve had no problems updating VMs from Sonoma 14.7.4 to 14.7.5, or Ventura 13.7.4 to 13.7.5. Those updates went quickly and without a glitch, but Sequoia has been another matter.
… bad news
I’ve now tried to update from Sequoia 15.x to 15.4 with three different VMs:
freshly installed 15.2
freshly installed 15.3.2
lightly used 15.3.2.
None of them had iCloud enabled, but they were each fairly standard in other respects, and all running in Full Security mode, in my virtualisers Vimy and Viable.
Each has failed early, just a minute or two after the update started to install. That was terminated, and the VM briskly rebooted back into its existing version of Sequoia. Shortly after logging back in, they displayed the panic alert.
One VM was so sick at that stage it couldn’t go any further, so had to be humanely destroyed. However, I managed to capture panic logs for the other two. In both cases, the panicked task was com.apple.Mobile, with com.apple.iokit.AppleVirtIOStorage(1.0) at the top of the kernel extensions in the backtrace. The panic occurred on different cores, and its cause was given as “Kernel data abort”.
And a more innocent bug
In the course of looking at this, I happened to notice that creation dates of files in Shared Folders were all incorrect, giving a standard date of Monday, 1 January 2001 at 00:00. All other creation dates in VM folders, the SSV, and even in iCloud Drive folders, were as expected, but none of those in Shared Folders.
However, when any of those mis-dated files or apps were copied into the VM’s local storage, the expected date of creation returned like magic.
I have checked this in VMs running 15.2, 15.3.2, 15.4, 14.7.5 and 13.7.5, and it’s identical in every one. I suspect this may have been going on for some time. Am I holding this one wrong too?
Over to you
Have you been able to update a Sequoia VM to 15.4?
Are file creation dates wrong in your VM’s Shared Folders?
Postscript
Thank you all for your responses. I’ve now confirmed that failure to update to 15.4 appears confined to M4 models, and doesn’t afflict my MBP M3 Pro at all. However, the shared folder creation date bug seems just the same there.
A kernel panic is completely different from an app crash. When apps suddenly vanish because of a bug or error, everything else should carry on as normal. When your Mac restarts of its own accord, or you find it shut down and have to start it up again, that’s almost certainly a kernel panic, and should be taken seriously.
Kernel panics occur when macOS can’t continue running any more due to severe (software) damage, and its only option is to restart itself in order to resume normal services. When this happens before the login window appears during startup, it normally results in a boot loop, as discussed elsewhere. This article covers the more common situation when a Mac restarts spontaneously and completes login without any further panic occurring.
Virtual machines (VMs) can also suffer kernel panics, as well as causing the host macOS to panic. Those should behave like other panics, although if you’re unlucky the VM might be damaged and unable to restart properly. If that happens, your only option is to try starting that VM up in Recovery, to see if it can be repaired there. If not, and you can’t get it to start up again, you’ll need to trash it and restore its last backup copy.
Save the panic log
Within a minute or so after restarting, a Panic Alert is displayed, inviting you to agree to send the panic log to Apple. Don’t simply agree to that, though, as it’s the only record of what happened. Panic logs used to be saved in /Library/Logs/DiagnosticReports, from where you could open them in Console, but more recently may be found somewhere closer to /var/db/PanicReporter. You therefore need to copy its contents as soon as it appears and before sending it to Apple.
If the alert isn’t already showing the panic log, click on its Report… button, then open a text editor like TextEdit. Copy the whole contents of the panic log into an empty text window and save it somewhere safe before clicking on the button to send the report to Apple. Once you’ve done that, the alert is dismissed and can’t be brought back.
It’s commonly assumed that sending a panic log to Apple means that an engineer will look through it and get back to you with some sort of diagnosis. That isn’t what the report does, though: it’s processed automatically and, while there’s nothing stopping someone at Apple contacting you about it, that simply doesn’t happen. Only by saving a copy of the log could you contact Apple Support and ask for their help. Also consider filing a Feedback report containing a description of what happened and your copy of the panic log, particularly if you have clues as to its cause.
Immediate actions
The three most common reasons for kernel panics are:
hardware (and device firmware) failure or error,
kernel extensions,
conflict with a peripheral.
If you suspect a hardware failure, or wish to rule that out, shut your Mac down once you have captured the panic log, disconnect all non-essential peripherals, and start it up in Diagnostics to run its hardware test routines. If you’re not reassured that all is well, don’t hesitate to get your nearest Apple store or authorised service provider to run their more advanced diagnostics as well.
On Apple silicon Macs, Diagnostics is different in relying on a hidden key combination: start the Mac up in Recovery by holding the Power button, and in the initial Options screen, hold Command-D until the Diagnostics Loader starts. This may require download of the disk image from Apple’s servers before testing can proceed, so a good Wi-Fi connection is important. Once loaded, there’s a hidden option for extended diagnostics that can be triggered by holding the Command-E key combination.
Panics associated with peripherals such as Thunderbolt docks and hubs are best diagnosed by running the Mac without the suspect hardware connected, to test if panics continue. If they do, and you remembered to save panic reports, even if you don’t understand their details you can still compare them to see if they look similar.
Kernel extensions
Third-party kernel extensions are normally found in /Library/Extensions or the app using them, from where macOS stages them into a folder in /Library/StagedExtensions where they’re protected by SIP. Most are only loaded on demand, so the mere presence of an extension there isn’t sufficient evidence to convict it of causing the panics. However, you should become suspicious when a third-party extension is named in the panic log as being part of the chain that may have caused it. Most software that used to rely on kernel extensions has now been updated to use system extensions or another modern replacement, so updating old software could solve the problem.
Tools for working with kernel extensions are detailed in the article on boot loops. If you need to remove a kernel extension, this article explains how to do that. One quick way to disable all third-party kernel extensions on an Apple silicon Mac is to start it up in Recovery, go through to the main Recovery window, open Startup Security Utility from the Utilities menu, disable loading kernel extensions and return it to Full Security.
Modern System Extensions don’t run with the same level of privilege as kernel extensions, so in theory shouldn’t be capable of causing kernel panics. However, experience has shown that the macOS kernel extensions required to support them can prove unstable and cause panics. This should be apparent from careful reading of the panic log.
Reading the panic log
Unlike app crash logs, panic logs are normally relatively brief and to the point. Although they may be non-specific and not help you much, in many cases they contain obvious clues as to what caused the panic. Formats have changed over the years, but the following sections are likely to prove worthwhile examining.
Immediate cause
At the very top, following the first word panic, the log may suggest a cause. This is most common when a memory leak is to blame, such as panic(cpu 8 caller 0xffffff80017729eb): "zalloc: zone map exhausted while allocating from zone kalloc.12288, likely due to memory leak in zone kalloc.48 (6586956000 total bytes, 137228148 elements allocated)"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.141.1/osfmk/kern/zalloc.c:3627
This first tells you which CPU core the panic occurred on. If you have repeated panics, keep a note of these, as they may cast suspicion on a core with a hardware problem.
In other cases, you may not be as lucky, and the cause is just given as an ‘exception’, or panic(cpu 0 caller 0xfffffe002f4e48bc): cannot find IOAESAccelerator
panic(cpu 0 caller 0xfffffe001abd5e94): Kernel data abort
so you’ll need to look for other clues. As the name implies, exceptions are conditions requiring special handling by the operating system. They include page faults, in which something has tried to access an invalid memory address, invalid instruction codes for the processor, and general protection faults which include a wide variety of other bugs. As far as the user is concerned, all exceptions indicate a bug or problem in the code that’s being run.
OS details
You may see a line like OS version: Not set yet
simply indicating that the version hasn’t been recorded yet. When it has, this gives its build number rather than version. Most importantly, you should see a statement of the kernel version running: Kernel version: Darwin Kernel Version 24.2.0: Fri Dec 6 18:57:59 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_VMAPPLE
You can check that against that shown in Software in System Information.
On Apple silicon Macs, you should also see the iBoot version, and the current level of boot security: iBoot version: iBoot-11881.61.3
secure boot?: YES
The latter is important, as running in Secure Boot means that no third-party kernel extensions have been loaded.
Memory leak
If there has been a memory leak, the panic log may well contain a breakdown of system memory zones giving more detailed clues. Zone Name Cur Size Free Size
vm objects 78041088 26795008
… Zone Name Cur Size Free Size
kalloc.32 280834048 3040
kalloc.48 6586956000 4896
kalloc.64 4241453056 5000896
…
Note how the Free Sizes of kalloc.32 and kalloc.48 are very small, and that of kalloc.64 is fairly low too. This is consistent with the kernel running out of memory in one of those zones. Further information may follow: Backtrace suspected of leaking: (outstanding bytes: 288)
Because there’s the suspicion of memory leakage, the panic log also gives a detailed backtrace of where it suspects that leakage is occurring, and details of the kexts involved in that. Note that those may not coincide with any kexts identified earlier as possible culprits.
Panicked task
This may simply be the kernel Panicked task 0xfffffe166cff1f18: 10735 pages, 374 threads: pid 0: kernel_task
or may give more specific information BSD process name corresponding to current thread: WindowServer
Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev
or Panicked task 0xfffffe1b55369798: 24964 pages, 8 threads: pid 800: com.apple.Mobile
This is the name of the process running its code at the time, and can be another clue as to where the problem lies.
You may also be given a list of kernel extensions that might be involved: Kernel Extensions in backtrace:
com.apple.filesystems.apfs(1412.141.1)[6DA33D13-4501-3D48-B4D8-0329E6AEC86D]@0xffffff7f84e7d000->0xffffff7f84fa4fff
dependency: com.apple.kec.corecrypto(1.0)[804DD660-F561-3444-A076-05D7A52D65E3]@0xffffff7f82746000
…
Third-party kexts
Whatever the cause, you should next look at the list of unloaded and loaded kexts forming the rest of the panic log. These are listed in the order that they were loaded, with the most recent kext at the top. As third-party kexts are the last to be loaded, the top of the lists start with any third-party kexts installed on that system and loaded at the time of the panic. last loaded kext at 939128480512562: >!UAudio 323.4 (addr 0xffffff7f86baa000, size 434176)
last unloaded kext at 948795488738566: >usb.IOUSBHostHIDDevice 1.2 (addr 0xffffff7f8556c000, size 45056)
loaded kexts:
>!ATopCaseHIDEventDriver 3430.1
…
In most cases, the name of the kext as you’ll find it in /System/Library/Extensions is the last part of the ID given. For example, the kext with the ID of com.apple.driver.AppleMobileFileIntegrity is named AppleMobileFileIntegrity.kext.
If those lists contain any third-party kexts, they should be immediately suspected as being the cause of that panic, unless another cause is apparent.
Summary
Save the panic log before sending it to Apple.
Consider running Diagnostics if there’s the possibility of a hardware problem.
Consider disconnecting a peripheral if that could be the cause.
Consider removing/updating any third-party kernel extensions, or better, disabling them altogether.
Read the panic log to provisionally identify its most likely cause, and try to address that.
Report the panic to Apple Support and/or via Feedback.
Keep a careful watch for any further panics, and be prepared to revise your provisional diagnosis.
Apple has gone to great lengths to make the transition to its new Arm-based Macs as seamless as possible. However, there are some major differences that most need to take into account before making their leap of faith from a cherished but now-ageing Intel Mac to a sleek and glitzy new M-series Mac. This article clarifies what are often points of confusion about what you can’t or shouldn’t do with a new Apple silicon Mac.
You can’t run any macOS before Monterey (or possibly Big Sur)
There are two ways to run macOS on Apple silicon Macs: natively, or in a virtual machine (VM). The oldest version of macOS your Mac can run natively is that current at the time that model was released. Models released before October 2021 can run macOS 11 Big Sur, and are the only Apple silicon Macs that can do so. Those released from October 2021 onwards can only run the version of macOS that was current at the time of their release, but can run older versions back to macOS 12 Monterey in a VM. Current models with M4 chips are even more restricted, as the earliest version they can run is macOS 15 Sequoia, although their VMs can still stretch back to Monterey if you need.
Catalina, Mojave and earlier were never released with support for Apple silicon Macs, so can’t be run on them, and will never be able to without emulating Intel processors in software, which is slow and unreliable.
A VM running on an Apple silicon Mac can’t run Big Sur, because the Virtio driver support required for virtualisation wasn’t complete then, and didn’t work until macOS 12 Monterey, although even there it offers fewer features than in Ventura. Full details are given here.
You can’t virtualise or run Intel macOS or 32-bit apps
Bundled in macOS is Rosetta 2, enabling you to run 64-bit Intel code and apps that are compatible with macOS 10.15 Catalina. Rosetta isn’t an emulation engine, but translates code from Intel to Arm instructions. However, it can’t translate 32-bit code, and it can’t translate operating systems like macOS. It does run 64-bit Intel apps amazingly quickly, though.
A VM running macOS on Apple silicon can therefore use Rosetta 2 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. Neither can it be used on the host Mac to run a VM of any Intel version of macOS.
If you need access to older or 32-bit Intel software, then the only practical way of doing that is on an Intel Mac that’s able to run Mojave or earlier.
You can’t install Intel kernel extensions
Rosetta 2 translation can’t support the privileged level of execution required for kernel extensions, so if you need your Mac to be able to load and use kernel extensions that are only available for Intel Macs, you can’t do that on an Apple silicon Mac. The great majority of more recent kernel extensions are now available as Universal versions that can also run native on M-series chips, but if your Mac still relies on an older kernel extension that’s Intel-only, then you can’t use that on a new Mac.
You can’t boot fully from an external drive
Unlike Intel Macs, Apple silicon models can only start their boot process from their internal SSD, as that’s required to support their Secure Boot. Although Apple silicon Macs can boot from external disks, early phases of that process still rely on the internal SSD and security policies (‘LocalPolicy’) saved there. This has several consequences:
An Apple silicon Mac can only boot from an external disk that is ‘owned’ by a user recognised by the primary system on its internal SSD. This is a valuable security measure, as without knowing login details for a suitable user of the internal SSD, it’s not possible to boot an Apple silicon Mac from an external bootable disk.
An Apple silicon Mac can only boot from an external disk if it can at least start that process from its internal SSD, normally requiring a bootable system on the internal SSD as well. If you do intend booting your Mac from an external disk, in practice you still need to install and maintain a bootable system on its internal SSD.
Total failure of the internal SSD results in failure to boot from external disks as well. A bootable external disk can’t ‘get you home’ in that emergency.
Apple silicon Macs don’t really boot fully from ‘bootable’ external installer disks, although they can still be used to install macOS when necessary, and may be required when installing older versions of macOS than currently installed.
Instructions for installing macOS on an external disk so that it can boot an Apple silicon Mac are given here.
You can’t use Boot Camp
Boot Camp allows you to start up an Intel Mac as if it’s a regular PC to run Windows. As Apple silicon Macs have completely different processors and other hardware, they can’t support that option. If you want to run Windows on your Apple silicon Mac, you’ll have to do that using a virtualiser like Parallels Desktop, and currently those can only run Arm versions of Windows, although Parallels is working on an emulator that can run some Intel versions. You can already try that out.
Avoid kernel extensions
Unlike Intel Macs, Apple silicon Macs don’t allow the use of third-party kernel extensions when running in Full Security mode. Before it can have those enabled, its startup security has to be reduced, and their use explicitly set in Startup Security Utility in Recovery mode. For most users that’s a significant deterrent. In almost all cases now, traditional kernel extensions should be replaced by new-style system extensions. You can read more about that here.
Avoid ‘cloning’ boot volume groups
Before Catalina and Big Sur divided the boot volume into a group of volumes, including System and Data, it was popular to make identical copies of, or ‘clone’, the volume containing the system. This is even more complex with Apple silicon Macs because of the multiple containers on their internal SSD. Although apps like SuperDuper and Carbon Copy Cloner can still create clones, they can’t include the whole of the internal SSD. That limits their usefulness, and they can readily fail.
The only way you can completely replace the contents of the internal SSD of an Apple silicon Mac is to restore it from an IPSW image file when the Mac is in DFU mode. That erases the SSD so that its Data volume then has to be restored from a backup or copy, not a task to be undertaken lightly or in a hurry. This is explored in detail here.
Don’t try using startup key combinations
Entering Recovery mode and accessing features that are controlled using startup key combinations on Intel Macs is completely different in Apple silicon Macs, and controlled using the Power button. Holding keys during startup does nothing for an Apple silicon Mac. I have an illustrated guide, details on Fallback Recovery, and on troubleshooting.
Neither can you reset the PMC or NVRAM using startup keys. The PMC in an Apple silicon Mac is completely different, and shouldn’t need to be reset. If it does, then restarting should suffice. NVRAM is primarily for the use of macOS not the user, and you should never have to reset it. Further information is given here.
Further reading
My page listing articles specific to Apple silicon Macs contains extensive information and guidance.
When you’ve decided that the only way to do what you need is inside a virtual machine (VM), working out how to accomplish that might appear challenging. Because all macOS virtualisers on Apple silicon Macs use features built into macOS, they’re also similar in use. This article explains how to get started.
VMs for macOS on Apple silicon Macs consist of a bundle folder, containing key files often named:
Disk.img or [name].hdd, the bootable virtual disk image, typically about 7 GB larger than the space allocated to the boot disk, stored in sparse file format, so taking far less space on the host’s storage;
MachineIdentifier or macid.bin, 68 bytes or so containing the unique ID for the VM;
HardwareModel or machw.bin, around 150 bytes;
AuxiliaryStorage or aux.bin, around 33 MB containing private data.
Some virtualisers also store a property list or other files such as config.pvs and VmInfo.pvi containing settings for the VM.
Location
Even a small, basic VM requires more than 40 GB of storage space. If it’s kept in a location that’s backed up by Time Machine or a third-party equivalent, it may quickly fill those backups. At the very least, a folder containing VMs should be excluded from normal backups, and perhaps copied to separate storage once a day.
VMs will also be included in any snapshots made of that volume. To avoid that penalty, they should be stored in their own volume that doesn’t have snapshots made of it, as well as being excluded from normal backups.
Download IPSW file
VMs are built from the complete image of an Apple silicon Mac boot disk provided in an IPSW file, currently around 16.5 GB but significantly smaller in older versions. Those should only be downloaded from Apple’s servers. Several sites provide links to those, including Mr. Macintosh, who also includes most beta-releases.
Most virtualisers also give direct access to the current release of macOS in its IPSW file, as that’s a feature provided by the API.
Create a VM
In this phase, the VM bundle folder is created with a unique MachineIdentifier, and the contents of the IPSW file are installed into the disk image. The latter is usually fastest from a file in the same volume, and some virtualisers follow Apple’s example of moving the IPSW inside the bundle to perform that, rather than copying it there and deleting that copy once the VM has been created.
The only control for this stage is to set the size of the disk image in Disk.img. As that’s stored as a sparse file, it’s wise not to skimp and end up with a VM that can’t update itself, for example. For recent macOS, a prudent minimum is 50 GB, and 100 GB gives ample room for the VM to contain additional apps, and for a functional Home folder.
At the end of this phase, the new VM is bootable, and ready for its first run, during which macOS will be personalised and the VM configured. Some virtualisers proceed directly to that first run, in which case their initial settings for it will then be used to run macOS.
First run
This follows the same sequence as the first run on a brand new Mac that has just been unboxed, starting with language and keyboard localisation, passing through migration and Apple Account, and ending in the running VM.
Migration during initial setup isn’t possible, as the VM has no access to any host storage, and if run later faces similar challenges. Although you may enable Location Services, VMs appear unable to use them, possibly because of their inability to use Wi-Fi settings. One of the first checks to perform in a new VM is to switch Time Zone selection to manual and set the correct zone.
Apple Account and iCloud access only work in Sequoia guests running on Sequoia hosts, and will fail for all other combinations.
As with other runs of a VM, you get to choose how many virtual CPU cores it will use, how much memory it will be allocated, display, network and other settings. Those aren’t built into the VM in the way that its size is, although some virtualisers let you save a VM’s settings as its default.
Traditionally, like Macs, VMs have been quitted by shutting them down, but most virtualisers also let you close a VM in a suspended state.
Virtual resources
All virtualisers should offer you a free choice of the number of virtual CPU cores, memory, network connections, and possibly display options. GPU access can’t be controlled directly, though.
Although it’s possible to run a VM in just a single CPU core, that’s slow and incapable of anything useful. In practice a minimum of 3 is wise, and using substantial apps is better with 4-6. Those must be balanced against the need for cores by the host. Similar considerations apply to memory, where 8 GB is barely sufficient, and 16 GB preferable.
Virtualisers should offer bridged networking, giving the VM its own IP address rather than sharing the host’s using NAT.
Enhanced features
VMs running older versions of macOS have more limited features. One simple way to enrich a VM is to run it through Screen Sharing, either locally on the same Mac, or if you prefer over a local network. This can add features such as:
Drag and drop files between Finder windows in the VM and those on the host, to copy them.
Full support for ISO keyboard layouts, including the key at the left of the numbers row..
A shared clipboard for copy and paste between the VM and the host.
Standard key shortcuts to make screenshots of windows or the virtual display.
Trackpad controls including gestures and smooth action with all guests.
The only time that you should never use this is when you’re going to update macOS in the VM. That will disconnect Screen Sharing and could lead to problems during or after the update.
One-off runs
One of the common purposes of VMs is to run quick tests whose effects you don’t want to be permanent. One method of doing this is to maintain a collection of VMs with different versions of macOS installed. When you want to test one out, duplicate that VM in the Finder (Command-D), run the copy, then when you’ve finished with it, delete it. Because duplicating the VM in the same volume results in file cloning, this is almost instant, and uses relatively little real storage space, while preserving the original.
This is also a useful technique when you want to test a potentially destructive process, as you can make as many duplicates of the original as you want. The only caution is that duplicated VMs have identical MachineIdentifiers, and you should never try running two VMs with the same MachineIdentifier at the same time.
Isolating VMs
One excellent reason for using a VM is to study potentially malicious software, and defences against it. It’s relatively easy to lock a VM down and ensure it’s completely isolated from the host, except in the limited data exchanged between its Virtio drivers.
To prepare a VM for use in isolation, start with a regular VM built using the version of macOS to be used in tests. Duplicate that, and running it with shared folders, load it up with any software to be used during the tests. Shut the VM down, and open it in Recovery mode to change its security, disable SIP and customise it in any other way you require, then shut it down again.
Open that VM using ViableS, deciding then whether you want it to have a network connection. That VM is then running in a sandbox, with no shared folders, and as isolated from the host as possible.
Settings and Vimy
Once you have set a VM up, you may want to run it using the same settings and with a minimum of fuss. My free Vimy runs VMs configured using Viable from a double-click, with a minimum of overhead; Vimy itself uses less than 50 MB of memory. That uses a property list containing settings such as the number of virtual CPU cores and memory, saved inside the VM bundle folder.
If you want to run an older version of macOS that your Mac doesn’t support, so can’t boot into, then the only option is to run it within your current macOS. You may be able to do that using one of two methods: virtualisation or emulation. Emulation is normally used when the older macOS runs on a different processor, while virtualisation may be available when the processors share the same architecture.
Running Intel macOS
If you want to run a version of macOS for Intel processors, including Catalina and earlier, then your Apple silicon Mac has to run a software emulation of an Intel processor for that to work. Although this is possible using UTM, emulation is slow and not reliable enough to make this feasible for everyday use. It’s impressive but not practical at present. For an Apple silicon Mac, that automatically rules out running any macOS before Big Sur, the first version with support for Arm processors.
Rosetta 2 for Apple silicon Macs isn’t an emulator, although it allows you to run code built for Intel Macs on Apple silicon. It achieves that by translating the instructions in that code to those for the Arm cores in Apple silicon chips. This is highly effective and in most cases runs at near-native speed, but Rosetta 2 can’t be used to translate operating systems like macOS, so can’t help with running older macOS.
Virtualisation
Virtualisation is far more practical than emulation, as it doesn’t involve any translation, and most code in the virtualised operating system should run direct on your Mac’s CPU cores and GPU. What is required for virtualisation to work is driver support to handle access to devices such as storage, networks, keyboards and other input devices. Those enable apps running in macOS inside the virtual machine (VM), the guest, to use features of the host Mac.
Virtualisation of macOS, Windows and Linux have been relatively straightforward in the past on Intel Macs, as they’re essentially PCs, and providing driver support for guest operating systems has been feasible. That has changed fundamentally with Apple silicon chips, where every hardware device has its own driver unique to Apple, and undocumented. Without devoting huge resources to the project, it simply isn’t feasible for third-parties to develop their own virtualisation of macOS on Apple silicon.
Recognising this problem, Apple has adopted a solution that makes it simple to virtualise supported macOS (and Linux) using a system of Virtio drivers. Those have been progressively written into macOS so that it works both as a guest and host, for services that are supported by a Virtio driver, and all versions of macOS since Monterey have been able to virtualise Monterey and later when running on Apple silicon.
The drawback is that, although features supported by Virtio drivers are readily implemented in virtualisers, those that aren’t can’t be supported unless Apple builds a new Virtio driver into macOS. Even then, that new feature will only be available in that and later versions of macOS on both host and guest, as support is needed in both before it can work.
Another important consequence of virtualisation being built into macOS is that different virtualising apps all rely on the same features, and act as wrappers for macOS. While different apps may offer different sets of features and present them in their own interface, virtualisation is identical inside them. I’m not aware of any macOS virtualiser on Apple silicon that doesn’t use the API in macOS, and they all share its common limitations and strengths. This also means that, when there’s a bug in virtualisation within macOS, it affects all virtualisers equally.
macOS support
Early Virtio support appeared first in macOS Mojave and gathered pace through Catalina and Big Sur, but the first version of macOS to support virtualisation of macOS on Apple silicon Macs was Monterey 12.0. That means that no Mac released after the release of Monterey in the autumn/fall of 2021 will ever be able to run Big Sur, as their hardware isn’t supported by it, and macOS 11 can’t be virtualised. The only way to retain access to Big Sur is to keep an M1 Mac that shipped with it, the last of which was the iMac 24-inch M1 of 2021. However, it also means that the latest M4 Macs can run Monterey in a virtual machine, even though the oldest macOS they can boot into is Sequoia.
When the host or guest macOS is Monterey, sharing folders between them isn’t supported, and the only way to share is through network-based file sharing, which is less convenient. Display support was enhanced in Ventura, which again is required on both guest and host for it to be available.
Support for iCloud and iCloud Drive access didn’t become 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. Only those built from the start to support Sequoia on a Sequoia host can support them.
Virtualisation can also have limited forward support, and is widely used to run beta-releases of the next version of macOS. This should be straightforward within the same major version, but testing betas for the next major version commonly requires the installation of additional support software. However, support for running betas is less reliable, and may require creation of a new VM rather than updating.
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.
Major limitations
The greatest remaining limitation in virtualising macOS on Apple silicon is its complete inability to run apps from the App Store, apart from Apple’s Pages, Numbers and Keynote, when copied across from the host. Even free apps obtained from the App Store can’t be run, although independently distributed apps are likely to be fully supported. 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. 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. Trackpads don’t always work as smoothly as on the host, particularly in older versions of macOS.
Strengths
One of the most important features is full support for running Intel apps using Rosetta 2.
That and other performance is impressive. CPU core-intensive code runs at almost identical speed to that on the host. Geekbench 6 single-core performance is 99% that of the host, although multi-core performance is of course constrained by the number of cores allocated to the VM. Unlike most Intel virtualisers, macOS VMs attain GPU Metal performance only slightly less than the host, with Geekbench 6 Metal down slightly to 94% that of the host.
VMs are mobile between Macs, even when built to support iCloud and iCloud Drive access. Because each VM is effectively self-contained, this is an excellent way to provide access to a customised suite of software with its own settings. As disk images, storage in VMs is normally in sparse file format, so takes a lot less disk space than might be expected. It’s also quick and simple to duplicate a VM for testing, then to delete that duplicate, leaving the original untouched.
Future
Virtualising macOS on Apple silicon has relatively limited value at present, but in the future will become an essential feature for more users. Currently it’s most popular with developers who need to test against multiple versions of macOS, and with researchers, particularly in security, who can lock a VM down with its security protection disabled.
Few apps that ran in Big Sur or Monterey are no longer compatible with Sequoia. As macOS is upgraded and newer Macs are released, that will change, and virtualisation will be the only way of running those apps in the future, much as virtualisation on Intel Macs is for older macOS.
There will also come a time when Apple discontinues support for Rosetta 2 in the current macOS. When that happens, virtualisation will become the only way to run Intel apps on Apple silicon.
However, until App Store apps can run in VMs, for many the future of virtualisation will remain constrained.
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;
access iCloud and iCloud Drive only when both host and guest are running Sequoia or later;
but they can’t run any App Store apps except for Pages, Numbers and Keynote.
Login
