Hi Quinn “The Eskimo!”,
Thanks for checking in with the VZ team and letting me know about general advice.
To be clear I wasn't complaining or suspecting the VZ framework or think it has any bug, but I was simply asking for tips and tricks to investigate and instrument when the specific VZ actions are called (I did ask for any undocumented tricks which you've advised are not available implicitly).
... I went ahead to instrument and add debug logging. I found the save/restore operations were done at measly 30-40MB/s, my app architecture is such that the VM runner can run as a background app which may/may not have a GUI.
On further debbuging I found a solution by setting NSAppSleepDisabled=true in the VM runner app's plist. I also wrapped the restoreMachineStateFrom and saveMachineStateTo code in a wrapper that starts a ProcessInfo acitivity with flags like .userInitiated, .latencyCritical, and .idleSystemSleepDisabled and raises the disk I/O policy (within the critical code) to IOPOL_IMPORTANT.
This resulted in following, as see in my runner app's logs:
2026-06-04T16:18:12.757Z [INFO] [Suspend] snapshot saveMachineStateTo took 1.50s for 1248.0 MB (831 MB/s)
...
2026-06-04T16:15:54.385Z [INFO] [Resume] restoreMachineStateFrom took 3.36s for 1280.0 MB (381 MB/s)
I'm still exploring how to further improve the restore logic, but the snapshot (saveMachineStateTo) was my immediate problem area which is fixed now (800MB/s throughput on a disk which does 4-5GB/s sequential IO seems great).
Sharing my findings and workarounds here if anyone in future may find this useful.
