Virtualization.framework VM execution ownership and crash reclamation on Intel macOS Monterey

Question

Daeigoloo OP

Created 2d

Replies 2

Boosts 0

Participants 2

Subject: Virtualization.framework VM execution ownership and crash reclamation on Intel macOS Monterey

Hello,

I’m investigating the lifecycle guarantees of Virtualization.framework on Intel macOS Monterey 12.7.x.

The specific scenario is a VZVirtualMachine running a Linux guest. I need to understand the ownership and reclamation behavior when the process holding the VZVirtualMachine is abruptly terminated without calling stop() or performing normal cleanup.

The key questions are:

For a specific VZVirtualMachine on Intel macOS Monterey, which userspace task/process actually owns the Hypervisor VM and the vCPU threads backing guest execution?

Is Hypervisor execution owned directly by the calling process, or by a separate process such as:

com.apple.Virtualization.VirtualMachine

or another Virtualization.framework backend?
If the process holding the VZVirtualMachine is terminated with SIGKILL or crashes without executing cleanup code, is the underlying guest execution context necessarily destroyed?

More specifically:
- Can guest vCPU execution continue after the client process has died?
- If a separate backend process owns the VM, is that backend guaranteed to terminate or destroy the VM when the client dies?
- Does this behavior apply to Intel macOS Monterey 12.7.x, or only to newer macOS releases?
Is there a supported diagnostic on Monterey that can map one specific VZVirtualMachine instance to the task/process that actually owns its Hypervisor VM/vCPU execution?

For example, would a diagnostic showing Hypervisor execution frames such as hv_vcpu_run in a process, combined with a reliable process-exit notification, be sufficient to establish that ownership relationship?
If the Virtualization backend can survive the client process, what supported VM-specific recovery or termination mechanism is available to another process?

The security property I need to establish is intentionally narrow:

If the userspace owner of a VM is abruptly destroyed, guest computation must not be able to continue indefinitely as an independent execution domain.

Persistent disk files or other inert VM artifacts are not the concern; the question is specifically about live guest/vCPU execution and its ownership lifecycle.

I’m looking for the supported architectural contract or diagnostic approach, not undocumented implementation details.

Target environment:

macOS Monterey 12.7.x
Intel x86_64
Virtualization.framework
Hypervisor.framework
Hardware virtualization available
No private APIs or privileged/kernel extensions

Thank you.

Answer 1

DTS Engineer OP

Apple

1d

The way you’ve phrased your question suggests that you only care about macOS 12, which is a bit weird. Most folks with questions like this are concerned about macOS 12 and later. So:

Is it that macOS 12 is your minimum deployment target, and thus you’re looking for answers for macOS 12 and later?
Or are you solely interested in the behaviour of macOS 12?

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

Answer 2

Daeigoloo OP

13h

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.