-
Notifications
You must be signed in to change notification settings - Fork 17
Home
This Wiki has some additional hints on using VMs on mac OS 12 based on your experience. NO warranties, this information is provided in the hope to be helpful for experienced users.
The macOS installation (restore) process takes some time, so don't get spooked when it seems stuck at "0%" progress for about a minute. If it's much longer than that then you can start to worry. Also the process has almost non-existent error reporting, so most errors come out simply as "Internal Virtualization Error" and thus are very hard to debug. Note that it requires additional disk space for the installation beyond just the space for the image, so make sure you have ample free disk space before you start, otherwise you simply get the above cryptic error that doesn't mention anything about disk space. Another wild one we encountered was a Timeout error (code 60) when using an excessively large image (when using 32Tb inadvertently instead of 32Gb).
macOS restore images specify the minimal requirements for the VM. However, it is possible to run VMs with different settings later. For example, you can use the default minimum (2 CPUs, 4GB RAM) to install macOS and then run the VM later with different settings, including lowering it, e.g., using 2Gb RAM still works with macOS 12.
The disk images used by macosvm are just flat files that correspond to the physical media (block device), so they can be mounted using hdiutil just like any other device. However, be careful with the boot disk since it contains a full set of partitions including recovery etc. so unwanted changes may render the VM unbootable. You can always use a clone copy (cp -c disk.img test.img) to have a test image to play with without the danger of modifying your gold master nor using too much extra space. However, it is probably better to add additional non-bootable images to the VM which can be modified safely to separate the data from the OS.
macosvm is ideal for running self-hosted GitHub runners. Latest runners now support macOS arm64 - see the "OSX arm64 (Apple silicon)" section under runner/releases. You can use an ephemeral runner, start it in the VM from cloned images (disk+aux) followed by shutdown on completion then each macosvm process effectively represents one active runner and you can delete the ephemeral cloned disk once macosvm terminates. This allows you to have a well-defined state which is guaranteed for each runner and code in the runner cannot influence any other runners. The only remaining security concern is networking, but you can use host firewall if you want to limit what the runners are allowed to access on the network.
Starting with macosvm version 0.1-2 you can use --ephemeral flag which automatically creates clones of images which are deleted when the process terminates which is ideal for runners (see the NEWS for 0.1-2).
The main purpose of macosvm is to run macOS VMs, but the Virtualization framework supports both macOS and Linux and thus macosvm has some rudimentary support for booting Linux images. You can specify the kernel, initrd (both must be uncompressed!) and kernel command parameters. For example, the following configuration can be used to run Debian VM images from debian-vm-aarch64 (after de-compressing gzip -dc initrd.img-5.10.70 > initrd):
{"os":"linux",
"storage":[{"type":"disk","file":"debian-rootfs-aarch64.img"},
{"type":"initrd","file":"initrd"}],
"bootInfo":{"kernel":"vmlinuz-5.10.70","parameters":"console=hvc0 root=/dev/vda1"},
"ram":4294967296,
"version":1,"cpus":2,
"networks":[{"type":"nat"}],
"audio":false}
By default the serial device will be created and mapped to stdin/out of the macosvm process. Note that any aarch64 kernel will work as long as it has virtio support (but many stock kernels don't).