Any way to speed up saveMachineStateTo and restoreMachineStateFrom

Question

Created 3d

Replies 2

Boosts 0

Participants 2

I'm trying to implement a VM snapshot & resume feature in a VM manager app. For some reason, both saveMachineStateTo and restoreMachineStateFrom to save machine memory to a file and restore saved vzstate/memory back for a VM is taking a lot of time on my system (XCode 26.3, macOS 15.7.7). The test VM has only sizes in the range of 4-8GB RAM.

Any tips or tricky to speed it up, for example, do like a CoW on the RAM so VM can be briefly paused and quickly resumed after while streaming the RAM in background? Or, any other ways for example for RAM compression, dirty-page tracking, or live/background RAM streaming to a file?

Or, to instrument and dig deeper, what's taking time?

Thank you.

Answered by DTS Engineer in 890061022

The short answer here is “No.”

I pinged the Virtualization team about this, and learnt some fascinating facts about how it works under the covers, but that doesn’t help with this problem. The Virtualization API is very high-level, and thus there’s not a lot wiggle room for you to explore improvements.

The speed is likely to be determined by the size of the guest’s RAM, and a few seconds is certainly expected. Is that inline with your “taking a lot of time” comment? Or is a way more than that?

Also, it’d definitely be worthwhile filing a bug about this. It seems likely that there’s stuff we could do to speed things up. If you do file a bug, there’s a few things I recommend that you do to improve its chances of gaining traction:

If you have the time, try to reproduce the issue with Virtualization sample code. That’ll confirm that the bottleneck is in Apple stuff, and unrelated to your code.
Then attach the tweaked sample to your bug. That’ll give us a clear understanding of your configuration. If you can’t do this, please describe the configuration in your bug’s text.
Reproduce the problem and then trigger a sysdiagnose, to capture all the surrounding state.
And for bonus extra credit, reproduce the problem again from within Instruments and include that trace.

Once you’re done, post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 1

DTS Engineer OP

Apple

1d

Accepted Answer

Recommended

The short answer here is “No.”

I pinged the Virtualization team about this, and learnt some fascinating facts about how it works under the covers, but that doesn’t help with this problem. The Virtualization API is very high-level, and thus there’s not a lot wiggle room for you to explore improvements.

The speed is likely to be determined by the size of the guest’s RAM, and a few seconds is certainly expected. Is that inline with your “taking a lot of time” comment? Or is a way more than that?

Also, it’d definitely be worthwhile filing a bug about this. It seems likely that there’s stuff we could do to speed things up. If you do file a bug, there’s a few things I recommend that you do to improve its chances of gaining traction:

If you have the time, try to reproduce the issue with Virtualization sample code. That’ll confirm that the bottleneck is in Apple stuff, and unrelated to your code.
Then attach the tweaked sample to your bug. That’ll give us a clear understanding of your configuration. If you can’t do this, please describe the configuration in your bug’s text.
Reproduce the problem and then trigger a sysdiagnose, to capture all the surrounding state.
And for bonus extra credit, reproduce the problem again from within Instruments and include that trace.

Once you’re done, post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 2

yadvr OP

1d

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.