Virtualization.framework: guest teardown after VM-owner process failure

I’m gonna recommend that you start out by reading this thread.

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

Thank you, Quinn. That's very helpful.

I have one follow-up regarding the completion of that cleanup.

On an Apple Silicon Mac running macOS 26.6, if a Virtualization.framework application's termination has been independently confirmed, is there a supported lifecycle event or ordering guarantee that establishes when its guest has actually ceased executing?

Specifically, is there any externally observable condition that another process can rely upon before starting a replacement VM?

Or should developers treat guest cleanup completion after unexpected application termination as unobservable through the public APIs?

I'm trying to distinguish confirmed application termination from confirmed guest teardown, without relying on private helper-process identities or the absence of guest telemetry.

Thanks again for your guidance.

So, let’s break this down into two cases:

• The host app works.
• The host app fails.

If the host app is working then the rules are simple: By the time the guest stops… it’s stopped. There may be cases where that doesn’t happen, see this thread for example, but I’d consider those to be bugs.

If the host app fails, it crashes for example, then the system will clean up on its behalf. Again, if that doesn’t happen then that’s Apple’s bug to fix.

However, there are no guarantees about the timeline for that. The API has no way to get some of meta handle to the guest, so that a replacement host app can get that meta handle [1] and ask the system whether that guest is completely done.

If you’d like us to add support for something like that then please do file an enhancement request for it. Make sure to include detailed info about your requirements, along with info about the high-level goal you’re trying to address.

If you do file an ER, please post your bug number, just for the record.

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

[1] Which would have to be from disk because an in-memory meta handle just pushes the problem up one layer.

Hi Quinn,

Thank you for the detailed explanation and for suggesting an enhancement request.

I've now submitted Feedback Assistant request FB25189315, covering persistent VM identity, independently verifiable teardown completion following host-application failure, and supported external termination where appropriate.

Your clarification about the absence of a guaranteed cleanup timeline and a successor-process verification API was particularly helpful in identifying the limitation.

Thanks again for your assistance.