Supported backing-file release semantics after stopping a Virtualization VM

App & System Services Core OS
full_sphere OP
Created
Replies 3
Boosts 0
Views 110
Participants 2

I am designing a macOS Virtualization application using RAW disk images, an EFI variable store and host directory sharing. I need to distinguish stopping guest execution from releasing host backing-file access.

I inspected the public declarations for VZDiskImageStorageDeviceAttachment, VZEFIVariableStore, VZSharedDirectory and VZVirtualMachine in the macOS27 SDK. The stop completion describes a stopped VM or an error; the backing types expose URL-based initialization. I could not identify a final backing-release event in those declarations. I would appreciate the supported contract, including any differences on macOS26 and macOS27.

For each of the three URL-backed surfaces:

  1. When are paths resolved and backing references opened? Can the framework reopen a path or lazily access shared descendants later?
  2. Does successful stop completion guarantee backing references are released and required writes persisted, or only that guest execution stopped?
  3. What object-reference release and queue/callback ordering is required before the application may safely reuse, replace or remove the backing objects?
  4. Can Virtualization helper processes retain backing access after the application's worker process exits? Is there a supported observable event covering those references?
  5. If no such release event is documented, what supported architecture should retain or quarantine these resources until release can be established?

I am not using physical block devices and am not generalizing their documented file-handle retention to URL-backed images, EFI stores or directory shares. Please link the public contract or clarify which behaviors are unspecified.

Answered by DTS Engineer in 909388022

See this thread.

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

Replies  3
Boosts 0
Views  110
Participants  2
DTS Engineer OP
Apple
Recommended

See this thread.

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

Thank you for the referral and the disk-image release guidance for macOS 27 and later.

Could you clarify the corresponding supported contracts for VZEFIVariableStore and VZSharedDirectory? This is a source-design question targeting macOS 27.0.1, build 26A434, on Apple silicon. I have not run a reproducer or established exact-build behavior.

  1. EFI variable store: After guestDidStop(_:) or a successful stop(completionHandler:), is the framework finished accessing and modifying the variable-store file, including outstanding operations and access held by framework helper processes? At what documented boundary may the host safely reuse, replace or remove that file?

  2. Shared directories: At either successful stop boundary, are all framework operations involving the shared directory and its descendants complete? Does that boundary cover files already opened through the share and references retained by framework helpers?

  3. Removing a share while running: What does setting VZVirtioFileSystemDevice.share to nil guarantee about in-flight operations and already-open guest files? Is there a supported completion notification establishing that the framework has finished accessing the formerly shared resources?

  4. Failure paths: How do these guarantees differ after an internal VM error or termination of the process hosting the VM? If neither stop notification establishes complete release, what public API or ownership pattern provides that boundary?

Please distinguish backing-resource release from persistent-data synchronization. Does any applicable release boundary also guarantee that pending EFI-store and shared-file writes have completed, or is separate synchronization required?

I am not assuming that releasing application references, observing object destruction, or reaping the hosting process proves that all framework-held access has ended. Host-side competing writers and application authorization are separate concerns.

Documentation references and supported-version limits would help. If the guarantees or exact-build applicability cannot be established publicly, an explicit statement of that limitation would also be useful.

DTS Engineer OP
Apple
Written by full_sphere in 911687022

Could you clarify the corresponding supported contracts for VZEFIVariableStore and VZSharedDirectory?

I would expect them to have the same semantics.

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