How to build a custom macOS VM on Apple silicon

Looking at how Software Update and the softwareupdate tool work is difficult using real Macs, because of the time it takes to set up macOS in just the right state. In this case, I wanted a recent but superseded version of Ventura with old versions of XProtect and other security systems. The simplest and most reliable way to create that was using a virtual machine (VM) running on an Apple silicon Mac, with the latest version of my free virtualiser Viable. This article steps through how I did that in less than 15 minutes.

I keep a library of VMs and the IPSW image files to create them on a Thunderbolt 3 external SSD that never gets snapshots made of it, nor is it backed up. I do keep separate copies of IPSWs and some VMs, but most of my VMs are built for a specific task and disposable afterwards.

In this case, my target macOS was 13.4, which is far enough behind us to be well out of date for its security data files, but not so old that it should operate much differently from 13.5.1. Having downloaded the 13.4 IPSW from Apple, via Mr. Macintosh’s compendium, I added that to my library, then duplicated it with Command-D. In APFS, of course, no copying is involved: instead, it provides an easy way for that clone file to be used to build a VM with minimum fuss.

I then installed that IPSW copy into a virtual disk of 100 GB using Viable’s Install… button. I used to use 50 GB for similar work, but as the main disk image within the VM is stored as a sparse file, there’s no point in being mean as it will still take the same amount of space on disk.

Once the installation is complete, I moved the IPSW file from inside the VM bundle using the Move IPSW… button, and trashed that clone file, leaving the original IPSW still safe in my library.

Configuring the VM for its first run is the first critical step. Normally, given a network connection, that first run might try to install outstanding updates. To prevent it from doing so, I thus turned the network connection off in Viable’s Network popup menu. Although the fresh VM doesn’t yet have any saved settings, to be sure that those would be written inside the VM bundle I enabled both override and overwrite of Saved settings. Otherwise, I configured it as I would do for most other VMs.

Without a network connection, the first run needs a bit more persuasion, when it prompts me to connect it to the Internet. It tries this twice, but all I do is click Continue on both dialogs, and it finally accepts that decision.

Normally with these lightweight VMs on their first run, there are two screens that need to be dismissed with the Not Now option: the first is for migration, and the second to sign in with an Apple ID. At least without an Internet connection, it doesn’t waste time asking for my Apple ID.

Otherwise the first run is straightforward, although the VM invariably starts up in Cupertino time. As soon as I can, I open its General settings, select Date & Time, and set its time zone manually. This is important when you’re going to access the VM’s logs.

In this case, I next wanted to turn all automatic updates off, so visited Software Update settings to do that. I then completed the first run configuration by setting the Finder’s windows up, ready to run my first set of tests in the VM. As those required a network connection, I shut down the VM to reconfigure the settings for its next run.

The only difference on that run was switching its network to use bridged Ethernet. I then ran the VM again, all ready to start testing Software Update in manual mode.

To keep a library of VMs running older versions of macOS, you can leave Software Update with all its automatic options disabled and manually install security data updates such as XProtect, either using softwareupdate or SilentKnight. While the VM will still display the red badge telling you that a macOS update is available, it will stick to the original version of macOS that you want for reference, research or testing. Who needs the complexities of dual-booting?

4Comments

Add yours

1

Udo Thiel on September 7, 2023 at 10:04 am

Thank you, that was exactly what I was looking for! I will print this out and nail it to the wall!

LikeLiked by 1 person
- 2
  
  hoakley on September 7, 2023 at 5:21 pm
  
  Thank you, Udo. Happy virtualising!
  Howard.
  
  LikeLike
3

Jon on September 7, 2023 at 2:16 pm

Thanks, Howard, for yet another great article and yet another great program!

I’d like to suggest that Viable be changed to *not* move the IPSW when the “Install” button is used. An alternative would be to add a checkbox to the Viable window to not move the IPSW into the bundle, but that would add clutter to the window.

I was momentarily confused the first time I did an “Install” because I didn’t expect the IPSW to be moved from where I had put it. However, the main reason to make this change is that it would make it much easier to make several VMs in sequence: one would just “Install” with the two existing open/save dialogs, without also having to repeatedly (1) duplicate the IPSW, (2) move the IPSW out of the bundle with two more open/save dialogs, and (3) send the moved IPSW to the Trash.

I _think_ I understand why the IPSW is being moved into the bundle when the “Download” button is used: it’s a good idea to save the downloaded IPSW, and where better than inside the bundle? But that reasoning doesn’t apply to the “Install” button, because the IPSW has already been saved somewhere by the user.

PS: Is there is a better place to make such suggestions, ask questions, and discus Viable and your other software? It and they are such great products that I’d love to connect with other users (and you, if possible) about them.

LikeLiked by 1 person
- 4
  
  hoakley on September 7, 2023 at 5:21 pm
  
  Thank you. This is a good a place as any to raise this, and it is something that I have devoted a lot of thought to before concluding that this is optimal behaviour.
  
  I too was surprised when I first got Apple’s example code up and running, to discover that it moved the IPSW file in this way, and set out to do what I then thought was better. It turns out that leaving the IPSW where it is, is almost guaranteed to result in the least good result.
  There are two relevant properties of IPSW files: they’re very large, at around 14 GB each, and much of that has to be copied into the VM’s disk image during installation, which can in the worst case take many minutes to complete.
  
  Worst case performance of installation occurs when it’s attempted using an IPSW from a different and slow storage device, like a hard disk or NAS, which are also the sort of place someone might well keep a library of IPSWs, given their size. On the other hand, the storage they’re most likely to install their VM on is considerably faster, such as an external (probably TB3) SSD. If that’s the case, by far the best option is to copy the IPSW into the VM immediately before installing it, exactly what happens at present.
  
  At the other extreme, consider another common situation like mine, where I keep my IPSWs and VMs in the same volume on a fast external SSD. There, moving (or copying) is instantaneous and uses no free space.
  
  Another important consideration is consistency: the first time you come across this behaviour, it might annoy, but you then always remember where to look for that IPSW, no matter where it was originally stored. Giving the user the option in Settings could lead to confusion.
  
  There’s a very easy way to create a succession of multiple VMs using the same IPSW: simply duplicate the number of copies you need. As they’re all clones, there’s no change in free space. When you’ve finished, then it’s a simple matter of moving them out of the VMs and trashing them.
  
  Of course if you want to make multiple identical VMs, you don’t even have to do that: simply create the first VM, then duplicate that into clones. The only caution is that, as they have identical machine IDs etc., you mustn’t run two of them concurrently, but relatively few users want to do that anyway.
  
  So yes, this is an annoying behaviour at first, but it actually is far better than trying to install an IPSW from where it might be, and until someone comes up with a better behaviour, I’d rather stick with that, please.
  
  Howard.
  
  LikeLike

Share this:

Related