When I first looked at lightweight virtualisation of macOS on Apple silicon Macs, one of the significant problems I identified was poor performance with storage. This was limited by the fact that I was still running VMs using Monterey, which only offers access to the VM’s disk image. This article updates those initial results with performance data from Ventura, including shared and external storage.

VM storage options

There are two options for storage in macOS guests: a VIRTIO Block Device, required for the boot volume group, including the Data volume, and a VIRTIO file system device, which can be used for shared storage with the host, but is only available when both guest and host are running Ventura.

Block Device performance

The Block Device is implemented in a disk image, which immediately raises questions as to its performance. The 2 TB internal SSD in my Mac Studio Max performs well: tested using Stibium or any of the popular disk benchmarking apps, its read speed is 8.1 GB/s for random files between 2 MB and 2 GB, and it writes at 7.3 GB/s. Create an unencrypted APFS Disk Image of 100 GB and read speed drops a little to 7.8 GB/s while write speed collapses to 1.3 GB/s. The latter is also more variable, ranging between 0.7-6.7 GB/s.

When running 13.0 in the VM and 13.0.1 on the host, and accessing a folder in the virtual Data volume using the VIRTIO Block Device, read speed was slightly faster than in my Monterey tests at 5.4 GB/s, but write speed fell to the same dismal 0.7 GB/s, around 10% of native performance.

I repeated those tests with the VM stored on an external SSD, an OWC Envoy Pro FX 4 TB, which delivers excellent native performance over Thunderbolt of 3.1 GB/s read and 2.1 GB/s write. Block Device performance from the VM was then near-native when reading, at 2.8 GB/s, but slower still when writing, at 0.5 GB/s.

These confirm my previous conclusion that, while reading from Block Storage is acceptably fast, writing to it is significantly slower, and could noticeably impair the performance of apps being run in the VM.

Shared storage performance

When shared storage is enabled in a VM, there are two quirks, which may seem strange at first. When deleting items from the shared folder in the VM, those are deleted immediately, and not held in the Trash. This might be the result of Apple’s design intention to make VMs as self-contained as possible, which prevents them from sharing access to a Trash folder.

The other oddity is that, seen from the VM, auto-mounted shared folder locations are within the VM bundle folder, which appears to be the VM’s designated ‘home’ folder. Although I have tried to set that to a more useful folder on the host, so far my efforts have failed. I suspect the reasoning is that this makes the VM self-contained and readily portable: as its shared folder remains within the VM bundle, copy that to another disk or Mac, and the shared folder and its contents are copied with it, a neat feature after all.

In contrast to Block Devices, the performance of shared folders is more impressive: on the internal SSD, read speed was 5.0 GB/s, and write 3.6 GB/s, about half that of the SSD accessed natively. On my OWC SSD, shared folder performance was essentially the same as native, reading at 2.9 GB/s and writing at 2.2 GB/s.

Copied VMs

Copying a complete VM bundle to another disk, such as the Envoy Pro FX, has the advantage that it takes the complete VM environment with it, shared folders included. After I had copied my test VM to the external SSD, and following these performance tests, I updated it in place to Ventura 13.0.1 without a glitch.

I also ran the VM on the external SSD on another Mac host. Although for many purposes these lightweight VMs are too restricted to be able to run many third-party apps, such as those from the App Store, and are denied access to iCloud, they’re an excellent platform for those who need to run a complete macOS environment on another Mac without booting the host Mac from an external disk.

The only potential snag with making copies of VMs is that they have the same Machine ID as the original. Should you try running an original and its copy at the same time, the results would be ‘undefined’, and not what you intended. As there’s currently no way to change an existing VM’s Machine ID, if you are going to run more than one macOS VM at a time, you’ll need to be watchful of this.

Conclusions

Lightweight virtual machines running macOS Ventura on Apple silicon:

• write to Block Device storage at around 10-20% of the speed of the host;
• write to shared storage at between 50-100% of the speed of the host;
• read from either storage type at 70-100% of the speed of the host;
• are effectively self-contained in their VM bundles, and mobile across disks and Macs;
• require care when running two at the same time, to avoid them having identical Machine IDs.