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.

Supported filesystem quota boundary for VZMacOSInstaller temporary writes
 
 
Q