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.
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
