Thanks, Quinn. Yes, that’s exactly the scenario I was asking about. Your recommendation makes the architectural boundary clear: we’ll use the normal guest shutdown / stop() paths during expected operation, and we won’t add a separate crash-detection cleanup mechanism. We’ll rely on Virtualization.framework to clean up the guest if the host terminates unexpectedly. We’ll also add the repeated force-quit test you suggested on our target macOS environment and monitor for any resource or VM-worker leakage. This resolves the question I was trying to answer. Thanks again for taking the time to walk through it so carefully.

Thank you, Quinn. This is very helpful and clears up the distinction I was struggling with between the supported Virtualization.framework lifecycle contract and the implementation details of the helper processes. In particular, your clarification that an unexpectedly terminated Virtualization.framework client should have its VMs cleaned up by the system, and that this is the expected behavior across macOS versions, answers the main question I was trying to resolve. I also understand now that process names, process relationships, and process lifetime are implementation details and therefore aren’t appropriate as an ownership or VM-liveness contract. I have one final architecture-level question, if you don’t mind: Is it reasonable for an application to rely on this client-lifetime → VM-cleanup behavior as part of the supported Virtualization.framework lifecycle contract when designing a bounded VM execution host? In other words, assuming the application still implements its own normal stop/timeout/cleanup paths, can it reasonably treat unexpected client termination as a failure case where macOS is expected to terminate the VM rather than allowing that VM’s execution to continue independently? I’m not asking for guarantees about private helper processes or implementation details — only whether that high-level lifecycle behavior is an appropriate supported assumption for application architecture. Thanks again for taking the time to clarify this.

Thanks for checking. For this specific investigation, I am primarily interested in macOS Monterey 12.7.x on Intel x86_64, rather than treating macOS 12 merely as a minimum deployment target. The reason is that I need to establish a security/lifecycle property for that exact host environment: if the userspace process responsible for a running VZVirtualMachine is abruptly destroyed, I need to know whether the live guest/vCPU execution is necessarily reclaimed and cannot continue independently. Behavior on newer macOS releases would certainly be useful context, especially if the ownership model changed over time, but a guarantee that applies only to newer releases would not establish the property I need for Monterey. So, ideally, I’m looking for the answer specifically for Intel macOS Monterey 12.7.x. If the behavior is the same from Monterey onward, that would of course also be very useful to know.