Post

Replies

Boosts

Views

Activity

Supported filesystem quota boundary for VZMacOSInstaller temporary writes
On Apple silicon with macOS 26.6.2 (25G83), I am preparing a small synthetic VM using Swift and public Virtualization.framework APIs. Before invoking VZMacOSInstaller, I need to establish a hard aggregate allocation bound covering its temporary extraction data and relevant helper caches, not just the supplied restore image, guest disk and auxiliary-storage URLs. The application-owned artifacts would be placed inside a fixed-size, capped filesystem. Unknown installer scratch remains part of the byte budget. Sampling free space or cancelling after a threshold is crossed is not a substitute for filesystem enforcement in this design. No installer has been started for this trial; this is an API-design question, not a reproduced installation failure. Is there a supported mechanism to select or constrain the filesystem for all VZMacOSInstaller and relevant helper temporary writes? In particular, is there a documented binding between a caller's temporary directory and independently managed installer-service storage, or another supported aggregate quota design? If the public API cannot provide this guarantee, an explicit statement of that limitation would help. I am not seeking private parameters, managed-container relocation, disabled system protections, or undocumented sandbox overrides.
0
0
101
3d
Supported filesystem quota boundary for VZMacOSInstaller temporary writes
On Apple silicon with macOS 26.6.2 (25G83), I am preparing a small synthetic VM using Swift and public Virtualization.framework APIs. Before invoking VZMacOSInstaller, I need to establish a hard aggregate allocation bound covering its temporary extraction data and relevant helper caches, not just the supplied restore image, guest disk and auxiliary-storage URLs. The application-owned artifacts would be placed inside a fixed-size, capped filesystem. Unknown installer scratch remains part of the byte budget. Sampling free space or cancelling after a threshold is crossed is not a substitute for filesystem enforcement in this design. No installer has been started for this trial; this is an API-design question, not a reproduced installation failure. Is there a supported mechanism to select or constrain the filesystem for all VZMacOSInstaller and relevant helper temporary writes? In particular, is there a documented binding between a caller's temporary directory and independently managed installer-service storage, or another supported aggregate quota design? If the public API cannot provide this guarantee, an explicit statement of that limitation would help. I am not seeking private parameters, managed-container relocation, disabled system protections, or undocumented sandbox overrides.
Replies
0
Boosts
0
Views
101
Activity
3d