File paths in vm.json are saved exactly as given during creation, rather than relative to vm.json
One thing I noticed while trying to make lots of VMs and copying VMs around is that the vm.json files end up having paths saved into it that are saved exactly as given when I created the VM.
This is fine if I never change anything about how and where I execute my VM, but this makes it complicated to change folder names or move execute around or make extra copies of a VM. Depending on the style of path specified, I end up having to modify the vm.json to account for other changes in the environment.
Ideally, I should be able to specify a single vm.json and have it work regardless of the path of where I moved the VM around to or where I'm executing from.
The issue
Relative paths
Relative paths function relative to the working directory used when invoking macosvm
For example, if I make a VM with relative paths like this:
cd ~/Desktop
macosvm -g --disk ./macos_13.6/disk.img,size=100g --aux ./macos_13.6/aux.img -c 4 -r 8g --restore ~/Desktop/Installers/UniversalMac_13.6_22G120_Restore.ipsw ./macos_13.6/vm.json
All of the files for the resulting VM will be saved under ~/Desktop/macos_13.6.
And inside the ~/Desktop/macos_13.6/vm.json it has saved the same ./macos_13.6/disk.img and ./macos_13.6/aux.img that were specified on the commandline.
Changing working directory:
Because the relative working directory structure is saved into the json, nothing will work if I change where I'm executing from:
cd ~
~/Desktop/macosvm --ephemeral -g ~/Desktop/macos_13.6/vm.json
2023-11-14 15:34:30.221 macosvm[21423:1426906] . cloning ./macos_13.6/disk.img to ephemeral ./macos_13.6/disk.img-clone-21423
2023-11-14 15:34:30.222 macosvm[21423:1426906] *** Terminating app due to uncaught exception 'FSClone', reason: 'Failed to clone './macos_13.6/disk.img' to './macos_13.6/disk.img-clone-21423': [errno=2] No such file or directory'
*** First throw call stack:
(
0 CoreFoundation 0x000000019b4b70e4 __exceptionPreprocess + 176
1 libobjc.A.dylib 0x000000019afd5fd0 objc_exception_throw + 60
2 macosvm 0x0000000104a0215c -[VMSpec cloneAllStorage] + 1316
3 macosvm 0x00000001049fe83c main + 9080
4 dyld 0x000000019b007f28 start + 2236
)
libc++abi: terminating due to uncaught exception of type NSException
Abort trap: 6
Changing folder names:
Because the relative working directory structure is saved into the json, nothing will work if I change the name of the VM's folder:
cd ~/Desktop
mv ~/Desktop/macos_13.6 ~/Desktop/macos_13.6_backup
~/Desktop/macosvm --ephemeral -g ~/Desktop/macos_13.6_backup/vm.json
2023-11-14 15:46:51.380 macosvm[21449:1429392] . cloning ./macos_13.6/disk.img to ephemeral ./macos_13.6/disk.img-clone-21449
2023-11-14 15:46:51.380 macosvm[21449:1429392] *** Terminating app due to uncaught exception 'FSClone', reason: 'Failed to clone './macos_13.6/disk.img' to './macos_13.6/disk.img-clone-21449': [errno=2] No such file or directory'
*** First throw call stack:
(
0 CoreFoundation 0x000000019b4b70e4 __exceptionPreprocess + 176
1 libobjc.A.dylib 0x000000019afd5fd0 objc_exception_throw + 60
2 macosvm 0x0000000102dfa15c -[VMSpec cloneAllStorage] + 1316
3 macosvm 0x0000000102df683c main + 9080
4 dyld 0x000000019b007f28 start + 2236
)
libc++abi: terminating due to uncaught exception of type NSException
Abort trap: 6
Absolute paths
I can avoid the problems of execution directories if I use absolute paths, as then there's no relative path structure to worry about. But I still have to fix up the paths in the vm.json if any names change anywhere along the hierarchy.
Ideal:
In my ideal world, the vm.json could store paths to the disk.img and aux.img relative to itself. By doing so, I could freely copy a VM folder around, rename it, change the relative execution path of my machine, etc., without needing to make the vm.json match.