VZVirtualMachine behavior when its owning process unexpectedly terminates

Question

Created 1d

Replies 2

Boosts 0

Participants 2

I'm looking for clarification on the supported lifecycle semantics of VZVirtualMachine on macOS.

Suppose process A creates and starts a VZVirtualMachine. While that VM is running, process A unexpectedly terminates or crashes.

What is the supported behavior of that same original running VM instance?

Is the VM automatically stopped or terminated when its owning process exits or crashes?
If the VM can continue running, is there a supported API for a newly started process B to reconnect to or obtain control of that same already-running VM instance?
If process B can reacquire the original VM, can it then force noncooperative termination of that instance, equivalent to using stop(completionHandler:) while the original controlling object still exists?
Is there a supported way for process B to determine authoritatively that the original VM has stopped after process A is gone?
Are there relevant differences between normal process exit, an unexpected crash, and forced process termination?

I'm specifically asking about the same original running VM instance. Creating a new VZVirtualMachine with the same configuration, or restoring previously saved machine state, would not answer the question.

If the owner-loss behavior is intentionally unspecified, or if there is no supported mechanism for another process to reacquire the same running VM, that would also answer the question.

I'm interested in the supported Virtualization.framework contract rather than experimentally observed behavior.

Environment: macOS 26.5.1 on Apple Silicon.

Answer 1

Engineer OP

Apple

8h

Could you provide some context for the question?

The behavior is one thing but you are likely looking to enable a specific use case that is larger than this. We might be able to better answer the question knowing the end goal.

Answer 2

rustamdev OP

5h

Thanks for the reply.

The use case is a security-sensitive execution system that runs a potentially faulty or unresponsive workload inside a Linux VM on Apple Silicon. The host process remains the trusted control plane.

The important property for us is that the guest must not be able to retain execution or resource authority indefinitely after the host has decided that the execution is no longer valid. We therefore need to understand the guarantees provided by Virtualization.framework itself, rather than relying only on experimentally observed behavior.

More specifically, assume a VZVirtualMachine is running and the guest becomes completely unresponsive — for example, its kernel is hung or stuck in a non-cooperative execution state.

From the host side, we then request that the VM stop.

We are trying to determine:

Does Virtualization.framework provide a supported host-controlled mechanism that guarantees termination of the VM even if the guest does not cooperate?
After that operation reports completion/success, is the guest guaranteed to no longer execute on any virtual CPU?
Is there any documented case where guest execution could continue indefinitely after the host has requested the strongest supported stop/termination operation?
Does this guarantee depend on guest cooperation, or is enforcement entirely outside the guest?
If the normal stop API cannot provide such a guarantee, is there another supported Virtualization.framework lifecycle operation intended for this use case?

We do not need a timing guarantee such as “termination occurs within X milliseconds.” The key requirement is whether the framework provides a host-enforced eventual termination guarantee independent of guest cooperation.

Environment: macOS 26.5.1, Apple Silicon.

I hope this explains the reason behind the question. I’m specifically trying to understand the supported Virtualization.framework contract, not undocumented or experimentally observed behavior.