Logging in with my Apple ID anywhere in the system (feedback assistant, Xcode, iCloud, etc.) fails when running under virtualization. Is this a known 'issue'? (networking in general is working fine)

I m trying to identify if my launched process is running on a local mac machine(desktop/laptop) or a virtual macOS X instance like AWS EC2, Azure, MacStadium etc. I have followed this link which searched for its limited providers in the output, but I m not bound to any limited providers and looking for a general solution which is applicable to all the providers. Is there some hardware/network/virtualization-related information that can be used to identify if the process is launched on a virtual MacOS instance? OR is there some system Information that I can use to be sure that my process is running on a local machine?

Virtualization framework is a high-level API to create macOS and Linux virtual machines. Hypervisor is a low-level API to build virtualization solutions without the need for a kernel extension. If you’re interested in containers on the Mac, check out the Containerization package and its associated container tool. Virtualization: Forums subtopic: App & System Services > Core OS Forums tag: Virtualization Virtualization framework documentation Using iCloud with macOS virtual machines documentation article Use iCloud on a virtual machine support article Running macOS in a virtual machine on Apple silicon sample code Running Linux in a Virtual Machine sample code Running GUI Linux in a virtual machine on a Mac sample code Building macOS apps with Xcode 26 on macOS 26 VM forums thread — This thread describes how the development experience in VMs has improved recently, and one remaining issue that you might bump in to. Hypervisor: Forums subtopic: App & System Services > Core OS Forums tag: Hypervisor Hypervisor framework documentation Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn, Following your recommendation by email, I’m posting this as a new thread. Thank you again for your guidance on Virtualization.framework. This is a separate question about ordinary host-side subprocess ownership and timeout recovery, not VM cleanup. Target environment: Intel x86_64 macOS Monterey 12.7.6, build 21H1320 Python 3.13.15 Public, supported mechanisms; no root privileges, private APIs or kernel extensions We are verifying a subprocess supervision component with this process structure: Trusted caller process → runner → pytest → private helper → native subprocess Each parent normally owns the consuming wait for its direct child. The private helper exclusively manages signalling and reaping of its native child. Outer processes do not signal saved helper/native PIDs. Cancellation is cooperative, through channels and file/token delivery. The runner observes its fresh pytest child, drains stdout/stderr with bounded retention, and consumes its exact child’s status after exit is observed. The runner, pytest and helper are launched in separate sessions. Consequently, signalling pytest’s process group would not cover the separately sessioned helper and its native child. The unresolved failure case is: A fresh pytest invocation starts. Cancellation delivery fails, or delivery succeeds but the work does not finish. The runner continues observation and bounded output draining within the remaining deadline. The deadline expires while pytest or processes below it may still be alive. The runner reports an unresolved outcome and may exit. The caller also has a bounded deadline and may return without consuming its runner child. Closing capture pipes can cause EPIPE and disturb the child’s cleanup. Exiting a consuming parent also relinquishes its ability to collect that child’s eventual status. The outer caller does not automatically acquire wait rights over pytest or its descendants. Our current policy retains affected files, preserves the original failure, and prevents subsequent tests from starting. We do not treat cancellation delivery, pipe EOF, successful signal delivery, or direct-child reap as proof that every descendant has stopped. This prevents false success, but does not resolve responsibility for work that remains alive. We have considered separating the caller’s response lifetime from the consuming owners’ lifetimes: the caller could return an unresolved response while both existing parents remain alive, draining output and collecting their direct children later. However, keeping them alive adds no termination authority and does not address a crash of either owner. I am not asking for an absolute guarantee against arbitrary kernel failures, or a promise that SIGKILL always completes within a fixed time. I would like to understand the supported architectural approach on Monterey. My questions are: Is retaining the existing consuming parents beyond the response deadline the appropriate pattern, or is there a supported macOS facility that provides a better ownership and recovery boundary? What safe termination authority should those owners retain over their fresh direct children? If process groups are part of the solution, what lifecycle rules are needed to avoid acting on a reused identifier, particularly after leader exit or reaping? Is there a supported way to manage the separately sessioned helper/native work if an intermediate parent exits? Or must each level independently retain its own supervision and cleanup responsibility? If the consuming owner itself crashes, is there a supported recovery mechanism for ordinary subprocesses? Would launchd or XPC materially help, and what limitations would remain for descendants in separate sessions? Which design constraint would you recommend changing: cooperative-only cancellation, the fixed lifetime of the runner, or the process topology? These are our current choices, not restrictions we assume macOS imposes. Our practical goal is a bounded response while an identifiable owner remains responsible for unsettled work, with appropriate termination authority and an honest unresolved outcome when cleanup cannot be established. The immediate qualification scope is only three simple tests, using shell bodies such as exit, kill -9 $$, and echo with ordinary exit statuses. They contain no intentional background work, pipelines or command substitutions. We would prefer a proportionate supported pattern rather than a new general supervision framework. If a reduced example would help clarify the question, I can provide one. Thank you for your time and guidance.

Virtualization.framework: guest teardown after VM-owner failure We are evaluating an ARM64 Linux guest using Virtualization.framework on macOS 26.6. If the process owning VZVirtualMachine is suspended, hangs on its VM queue, or is forcibly terminated: Does Apple provide a supported guarantee that termination of the owning process also terminates all guest execution resources? Which documentation defines this behaviour? Can a separate surviving process identify and forcibly stop that specific VM through a public API? What supported positive observation can that surviving process obtain to confirm guest execution has ended after the owner is gone? Are any teardown deadlines guaranteed, or must they be measured? We need to distinguish confirmed teardown from owner-process exit, lost telemetry or disconnected IPC. We are seeking documented lifecycle behaviour and supported APIs, without relying on private framework internals.

Hi Quinn — following up from DTS case 22070584. I'm working on a Windows compatibility runtime (Wine plus a CPU translator) that runs natively on Apple Silicon. 64-bit x86 Windows programs work fine. 32-bit ones don't, because they need address space in the low 4 GB: guest pointers are 32-bit, and some Windows structures sit at fixed addresses like 0x7ffe0000 that programs read directly. On arm64 I can't get anything down there: task_info(TASK_VM_INFO) -> min_address 0x100ea0000 mmap(0x7ffe0000, MAP_FIXED) -> ENOMEM mach_vm_allocate(0x7ffe0000, VM_FLAGS_FIXED) -> KERN_INVALID_ADDRESS There's also nothing below 4 GB to remove: mach_vm_region finds no entry there at all, and mach_vm_deallocate(0, 4 GB) returns KERN_SUCCESS without changing anything. Building with a smaller __PAGEZERO doesn't help either — every size I tried (0x1000, 0x4000, 0x10000, 0x100000, 0x1000000, 0x10000000, 0x80000000) gets SIGKILLed before main, with no crash report. Ad-hoc signing, the hardened runtime and -no_pie made no difference. I did notice /usr/libexec/rosetta/runtime is arm64 with no __PAGEZERO segment at all and __TEXT at vmaddr 0, so the kernel can clearly do this, at least for platform binaries. Is there a supported way for a third-party arm64 process to map below 4 GB — an entitlement, a spawn attribute, something I've missed? If the answer is no, that's fine, I'd just like to know so I can stop looking and plan around it. I have two small test programs that print all of the above if they'd be useful.

Summary We use Virtualization.framework to run macOS guests on Apple silicon. When the guest is updated from macOS 15.6.1 to 15.8.1 inside the VM, the update writes a new boot loader, mBoot-20457.1.29, into the VM's auxiliary storage. After the update, the guest kernel can use only about 1.75 GB of the configured memory. The kernel wires the rest as VM_KERN_COUNT_BOOT_STOLEN. The guest swaps all the time, and builds become 7 to 18 times slower. The fault stays after a cold boot. The guest boot-args value is empty. Environment Host: macOS 26.7.2 (25G320), Apple M3 Pro, 36 GB Guest before the update: macOS 15.6.1 (24G90), installed from the IPSW Guest after the update: macOS 15.8.1 (24H32), installed with softwareupdate inside the guest VM configuration: VZMacOSBootLoader with the default ROM, VZMacPlatformConfiguration, VZMacAuxiliaryStorage, memorySize = 15032385536 (14 GiB), CPUCount = 6 A customer sees the same fault on macOS 26.6.2 with an M2 Pro host. Steps to reproduce Create a macOS 15.6.1 VM from the IPSW. Set memory to 14 GiB. Boot the guest and confirm the RAM. vm_stat accounts for about 14 GiB. In the guest, run: sudo softwareupdate --install "macOS Sequoia 15.8.1-24H32" --restart --agree-to-license --user <owner> --stdinpass After the guest restarts, run sudo zprint | grep BOOT_STOLEN and vm_stat. Shut down the VM, start it again, and do step 4 again. Expected result The guest can use about 14 GiB of RAM, as it could before the update. Actual result 15.6.1, before the update 15.8.1, after the update and after a cold boot hw.memsize 15032385536 15032385536 RAM accounted for by vm_stat (free + active + inactive + speculative + wired + compressor) about 13.99 GiB about 1.75 GiB VM_KERN_COUNT_BOOT_STOLEN not measured 12,845,072 KB (about 12.25 GiB) Swap activity Swapins 0, Swapouts 0 Swapins 225,835, Swapouts 267,316 nvram boot-args empty empty Auxiliary storage contents after the update The auxiliary storage has two boot loader slots. Each slot has a 16-byte HUFA header: magic, version, upgrade count, and slot offset from 0x4000. Header offset Upgrade count Slot offset Boot loader 0x4000 1 0x24000 iBoot-11881.140.96 (the original 15.6.1 boot loader) 0x5000 2 0x224000 mBoot-20457.1.29 (written by the 15.8.1 update) The VM boots the slot with the higher count, which is mBoot-20457.1.29. Workaround test (customer) The customer worked on a copy of an affected VM. They copied the iBoot-11881.140.96 slot over the active mBoot-20457.1.29 slot in the auxiliary storage. macOS 15.8.1 then booted with about 14 GB of usable RAM, and the RAM stayed correct after cold boots. Their results: Extraction and validation of nine Xcode versions: 9 to 10 minutes (it was 68 to 102 minutes). Xcode 26.1.1 simulator installation and cache preparation: under 7 minutes (it was more than 2 hours). This workaround changes Apple's signed firmware by hand... Not really a good idea. Related report A public report describes the same fault with UTM and the same boot loader version. It also says that the kernel computes the stolen value from the memSizeActual and memSize boot parameters that the boot loader supplies. The author filed FB24992831 (https://wadetregaskis.com/the-macos-sequoia-15-8-updater-stole-my-ram/) Questions Is this a known fault in mBoot-20457.1.29? Will a later update fix it? Is there a supported way to make a VM boot a specific boot loader slot? Or a supported way to roll back the boot loader in VZMacAuxiliaryStorage? Is there a configuration on the host or in the guest that makes mBoot pass the full memory size? We'd prefer to not make nvram read only if the new mBoot is absolutely needed for some reason.

I have so far been unable to enrol a macOS 27 beta VM in to Jamf since initial beta release. Is this by design? I can’t find any documentation or posts on apple developer forums about this anywhere. My agentic coding session has done some probing around in the VM and it thinks something is going wrong with Secure Keychain within the VM. Everybody on my team is observing the same behaviour as this, and I’ve had it happening across two different laptops (one of them which is, itself, running the latest macOS 27 Beta, and the other which I created a Beta VM by installing Tahoe in the VM, logging in to iCloud, and enabling Beta channel updates) The only thing we’ve found we can do so far is to join to Jamf in Tahoe first, but the problem I have there is, often times the option for Beta channel updates just doesn’t present itself in System Settings -> Software Update after signing in to iCloud, and I don’t know why it sometimes does but often doesn’t. Logs from agentic coding session below: The core log evidence This is the whole causal chain, from the 27 guest's unified log, inside 370 microseconds. Innermost failure first: 05:24:04.967316 apsd: (CryptoTokenKit) [com.apple.CryptoTokenKit:sepkey] <sepk:* kid=0000000000000000>: (apsd) unable to generate key: error e00002e2(-536870174) ACL=<SecAccessControlRef: dk;ock(true);odel(true);osgn(true);oa(true);okd(true)> 05:24:04.967433 apsd: (Security) [com.apple.security:seckey] SecKeyCreateRandomKey_ios failed: NSOSStatusErrorDomain Code=-25308 "Failed to generate keypair" (errSecInteractionNotAllowed / Interaction is not allowed with the Security Server.) 05:24:04.967574 apsd: (DeviceIdentity) com.apple.MobileActivation.ErrorDomain Code=-1 "Failed to create reference key." 05:24:04.967600 apsd: [com.apple.apsd:courier] APSBAAClientIdentityProvider failed to obtain a BAA cert, error: com.apple.MobileActivation.ErrorDomain Code=-1 "Failed to create reference key." 05:24:04.967686 apsd: [com.apple.apsd:courier] <APSCourierConnectionManager; production>: Stream error occurred for : APSErrorDomain Code=1 "Told not to connect after fetching server bag: (null) - closing stream" Read bottom-up: Secure Enclave key generation fails, so MobileActivation cannot create the reference key, so apsd cannot obtain its BAA device-identity certificate, so APNs tells it not to connect. kid=0000000000000000 means there is no key id at all. Then every courier line reports Connected on 0 interfaces, and mdmclient sets its PushWakeTopics only to get Connection Invalid for service com.apple.apsd and tear down. The command to regenerate it: log show --predicate 'process == "apsd"' --last 60m --info | grep -iE 'BAA|unable to generate key|server bag'. New control, collected just now mac26 happened to be running, so I got the comparison. macOS 26.6 (25G72) guest, same host, same network, 3 days uptime: BAA_FAILURES: 0 SEPKEY_FAILURES: 0 APNS_SOCKETS: 192.168.64.8.52286 -> 17.57.146.7.443 ESTABLISHED 192.168.64.8.52285 -> 17.253.77.203.443 ESTABLISHED (+ 3 more into 17.0.0.0/8) No BAA or courier complaints at all over 6 hours, and live connections into Apple's network. So a virtualised guest per se is fine; the 27 guest specifically cannot mint the key. The physical host, also on macOS 27.0, likewise logged zero of both failures over 3 hours.

Hi everyone & DTS engineers, I am developing a macOS application that uses Apple's Virtualization framework and vmnet APIs. In my main application bundle, I have requested and received approval for the restricted entitlement com.apple.vm.networking. The main app works as expected with bridging/vmnet features. Now, I have embedded a command-line helper binary inside the app bundle (Contents/MacOS/). The helper is configured as follows: Set up with com.apple.security.app-sandbox = true Inherits App Sandbox rules (com.apple.security.inherit = true) Signed with com.apple.vm.networking = true in its entitlements file. However, when launching or invoking networking features from this helper binary, it fails to execute the expected vmnet functions / gets blocked at runtime. My questions for DTS / Apple Engineers: Since com.apple.vm.networking is a restricted entitlement tied to a specific App ID / Provisioning Profile, does an embedded CLI helper tool with its own Bundle ID need to be explicitly registered and granted this entitlement separately in the Developer Portal? If the helper uses com.apple.security.inherit, does AMFI still strictly evaluate the helper's own provisioning profile signature against com.apple.vm.networking independently of the main app bundle? What is the recommended architectural pattern for vmnet access when using helper tools—should network creation stay strictly in the main app process and communicate via XPC, or should the helper tool be granted its own matching profile and entitlement? Thanks in advance for any insight!

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: When are paths resolved and backing references opened? Can the framework reopen a path or lazily access shared descendants later? Does successful stop completion guarantee backing references are released and required writes persisted, or only that guest execution stopped? What object-reference release and queue/callback ordering is required before the application may safely reuse, replace or remove the backing objects? Can Virtualization helper processes retain backing access after the application's worker process exits? Is there a supported observable event covering those references? 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.

There have been 2 serious regressions in the hypervisor framework since developer beta 6 of macOS 27 that have continued into the final release, and the first beta of 27.2 The first is that since developer beta 6 of macOS 27, virtual machines that have an Apple ID with iCloud+ signed in fail to route traffic in Safari through iCloud Private Relay despite it being on. Parallels, UTM, VirtualBuddy have all been tested and the issue applies to all of them, exposing the host machine's IP address. I have reported the issue since I discovered it and there hasn't been any communication that Apple even knows its an issue to my open report in Feedback Assistant. The second issue is a newer one, and it affects macOS 26.6.2 and earlier virtual machines. Attempting to install 26.7 through the built-in software update causes the virtual machine to black screen upon reboot during the installation. Forcing the machine off and back on causes the virtual machine to revert back to macOS 26.6.2. There has been no available IPSW file to test if a clean install of 26.7 in a virtual machine is a viable workaround, or to see if there is a bug in the updating mechanism or bug in the 26.7 release itself in virtual machines. The Parallels Desktop forum is beginning to get reports from users of that software of the same black screen issue trying to update their own 26.6.2 VMs to 26.7. These issues have also not been corrected in either 27.2 Beta 1 nor 26.7.1 Has anyone found a workaround to either of these 2 issues, or submitted similar reports and got any kind of response from Apple? The feedback reports about these issues are FB24828992 and FB24791716

We are evaluating Virtualization.framework for a disposable, offline synthetic Linux test VM on Apple silicon (observed host: macOS 26.5.1, build 25F80, arm64). The VM has no network devices, host directory shares or host-execution sockets. Normal guest shutdown and VZVirtualMachine.stop(completionHandler:) have been exercised with the owning process alive. We have not injected owning-process death. Apple's GUI Linux sample documentation says the VM continues until guest shutdown or app quit. The stop API documents successful completion or error through the owning VM object. We need to distinguish those normal paths from abrupt loss of the process that actually owns that object—not just termination of an outer controller. Could you clarify the supported contract for these cases? If the owning process crashes or is terminated with SIGKILL, is the associated VM guaranteed to stop executing? If so, what public contract specifies the applicable macOS versions, completion semantics and any bounded shutdown deadline? Does this require application cleanup code or retention of another client? Can a separate surviving process use a supported public API to identify the exact previously running VM and obtain terminal-state proof after the owner is gone? Is there a supported adopt/query/stop mechanism, or is there intentionally no such cross-process interface? If automatic teardown is guaranteed, what supported observation establishes that this specific VM can no longer execute or initiate I/O before its task-owned backing resources are removed? An accepted stop request or disappearance of an app PID would not by itself establish that condition for our test controller. If no such contract or observation exists, is the supported design to retain a live owner and treat unexpected owner loss as an unresolved state requiring a different recovery boundary? Please distinguish documented guarantees from current implementation behavior, including behavior when the virtualization backend itself fails or becomes unresponsive. We are asking about lifecycle containment, not graceful guest filesystem shutdown, saved-state restoration into a new VM, or serializable guest hardware identity. References to the appropriate public documentation would be helpful.

macOS guest (Virtualization.framework) freezes with all vCPUs halted right after a macOS update reboot - 3/3 on a macOS 26.7.1 (25G309) M4 host, seen with both UTM and Parallels Summary On a macOS 26.7.1 (25G309, beta/seed build) host with an Apple M4, every macOS guest that runs an in-place macOS update freezes at the same point: the in-OS phase of the update completes and reports success, the guest requests a reboot, records a shutdown stall 9 seconds later, reboots twice, shows the update progress screen for about a minute, and then stops. All four vCPUs enter WFI and never wake, paravirtualized graphics stops submitting, no I/O is pending on the host side, and no host service logs an error. The VM never recovers and has to be killed. Reproduced 3 out of 3 times, under two different front-ends (UTM and Parallels Desktop) and two guest versions (15.7.x and 26.6.2). Environment Host: iMac (Mac16,3), Apple M4, 16 GB RAM, macOS 26.7.1 build 25G309 (seed channel), installed the evening before the first failure. Primary guest: macOS 15.7.9 (24G830), hardware model VirtualMac2,1, 4 vCPUs, 6 GB RAM, 90 GB raw disk image (virtio-blk) stored on an external USB SSD. Networking bridged to the built-in Ethernet port. Devices enabled: memory balloon, audio, entropy, clipboard sharing; display 1920x1200 with dynamic resolution. Front-end for the primary case: UTM [version], Apple Virtualization backend. Guest was the only VM running, cold-booted, window open. Update being applied: MSU_UPDATE_24H23_patch_15.8_minor (15.7.9 -> 15.8). Other cases: a macOS 26.6.2 guest under UTM; a macOS 15.7.7 -> 15.8 guest under Parallels Desktop 26.4.2 (57518). Steps to reproduce Cold-boot a macOS 15.7.9 guest under Virtualization.framework, as the only VM on the host. In the guest: System Settings > Software Update > install macOS 15.8. Let it reboot. Expected The guest installs the update and boots into 15.8. Actual — timeline of the primary case (R = the moment Software Update requested the reboot; absolute timestamps are in the attached logs) R-23 min to R-5 min: UpdateBrainService prepares the update inside the guest, writing about 25 GB (two "disk writes" resource reports: 16.5 GB then 8.5 GB). No errors. R-1:56: post-logout install configured; disk space check passes (5.7 GB required, 40.7 GB free). R-1:44: "SUOSUPostLogoutInstallOperation: Applying MSU update". R: "Applied MSU update"; FileVault stash committed ("kAppleFDEKeyStore_commitStash success"); "Rebooting (success = 1, displayAsleep = 0, shutdown = 0)". This is the last line the guest ever writes to install.log. R+9 s: the guest writes a shutdown_stall diagnostic report. R+10 s: host sees ParavirtualizedGraphics "Device reset" / "PGDisplayNub[0]: Destroyed" (reboot #1). R+1:20: second device reset (reboot #2), 70 s after the first. On the host, the vmnet interface is torn down and recreated with no error, the AppleVirtualPlatformIdentity service completes boot attestation with no error, and the guest's graphics driver renegotiates ("Guest requested binary version: 209"). R+1:38: host logs "PGDisplay[0]: Change display mode to 3606x2254" — the guest is on the update progress screen. R+1:41 to R+2:25: the guest's six PGFifoThreads go idle one at a time. The progress bar stops partway. No further activity of any kind. R+11:35: spindump of the VM host process (com.apple.Virtualization.VirtualMachine): 0.042 s of CPU over a 5 s sample all four com.apple.virtualization.thread.cpu-N threads in Hv::Vcpu::run() -> HvCore::Hypervisor::VcpuStateManager::wait_for_interrupt() -> __psynch_cvwait cpu-0/cpu-1 wake on a ~20 ms timer tick and return to WFI; cpu-2/cpu-3 had not run for seconds no thread in any file read, write or fsync (no host I/O outstanding) PGFifoThreads last ran 550–614 s earlier process state Ss (sleeping), not U Host kernel log for the window: no USB, APFS, I/O error, timeout or reset entries. No hardware video decoder (AppleAVD) errors. The VM was left for over an hour with no change, then killed. Second case (same host, same day, UTM, guest macOS 26.6.2) Identical signature: two graphics device resets 69 s apart, display mode set 3 s after the second one, last graphics activity about a second later, then all vCPUs idle in WFI for ~6.5 hours until the VM was killed. Third case (same host, same day, Parallels Desktop 26.4.2, guest 15.7.7 -> 15.8) The guest was suspended in the middle of its update and resumed later. On resume ("-[_PGDevice willResumeWithSuspendState:error:]: Begin resume", preceded by "[VirtualMachineParameterBuilder] Failed to get auxiliary file identifier"), paravirtualized graphics never came back — its FIFO threads ran once and never again — and the guest's vCPUs sat in WFI. This may be a separate save/restore defect, but the end state is the same. What I believe is ruled out The in-OS phase of the update: it completed and reported success. Guest kernel panic: vCPUs are halted, not spinning, and there is no panic report on the guest's data volume. Disk space: 40.7 GB free in the guest at install time. Host storage stall: no uninterruptible wait, no I/O frames in the spindump, no kernel storage errors. Host hardware video decoder: no AppleAVD errors in the primary case. Host services: vmnet and AppleVirtualPlatformIdentity completed normally seconds before the hang. Guest memory: 6 GB allocated. Not yet isolated The VM images live on an external USB SSD; not yet reproduced from internal storage. The memory balloon, audio and clipboard-sharing devices were enabled; not yet reproduced with them disabled. A third-party VPN client was running on the host (guest networking is bridged, so guest traffic bypasses the host tunnel, but host firewall rules could still affect bridged frames). I don't have a confirmed-good in-place guest update on this machine from before 26.7.1, so I can't state with certainty that this is a regression. Frequency 3 of 3 attempts on this host. Attachments / available on request spindumps of the hung VM host process (primary case and second case) host unified-log excerpts for both hang windows the guest's full install.log the guest's shutdown_stall report and the two UpdateBrainService disk-writes reports sysdiagnose captured while hung, if obtained Has anyone seen macOS guests stop at this point on the 26.7.x seeds? If you can reproduce, your host build, hypervisor, and whether the VM image is on internal or external storage would be useful to compare.

After a normal macOS guest shutdown, what is the documented lifecycle for VZDiskImageStorageDeviceAttachment? What cleanup is required before the host can safely read the backing disk image, and is there a supported completion notification for outstanding I/O?

Environment: Apple silicon host, macOS 15.6 (24G84). An arm64 command-line launcher is ad hoc signed; strict signature verification passes and its only entitlement is com.apple.security.virtualization. An Apple macOS 15.6 restore image reported a supported hardware model. The VM configuration validated with 4 vCPUs, 8 GiB RAM, a fresh macOS auxiliary store, a 64 GiB writable raw disk, and a separate read-only raw disk. No guest networking, directory sharing, or socket device was configured. One observed sequence: Load the restore image, select its supported hardware model, create the auxiliary store and disk, validate the VM configuration, then call VZMacOSInstaller.install(completionHandler:). The Apple installation service starts; its logs reach RestoreOS and show a signing-server response. The host logs also record the service's sandbox denial and repeated CSSM permission errors: Sandbox: com.apple.Virtualization.Install deny(1) network-outbound /private/var/run/systemkeychaincheck.socket Can not connect to /var/run/systemkeychaincheck.socket: Operation not permitted CSSM Exception: 100001 UNIX[Operation not permitted] RestoreOS mode device connected AMAuthInstallRequestSendSyncWithHeader: received tss response The guest disk gained GPT/APFS volumes and roughly 17.6 GB of data. After about 11 minutes without a completion callback, the operator stopped the launcher. Exit status 130 reflects that interruption, not a result from VZMacOSInstaller. This launcher did not observe VZMacOSInstaller.progress. No VM retry has been performed since the incident. The socket and its host launchd service were present; a host-only connection succeeded outside the command sandbox. The denial was recorded against Apple's installation XPC service, and restore activity continued after it. Restore-image support, initial VM configuration/attachment construction, and launcher signature verification succeeded. A later restore or storage problem has not been ruled out. XPC sandbox socket denial is proven; cause of provisioning non-completion remains unproven. There is no terminal installer result from this attempt. Questions for anyone familiar with this installation path: Can denial of the installation service's connection to /var/run/systemkeychaincheck.socket prevent VZMacOSInstaller from completing? Are repeated CSSM Exception: 100001 UNIX[Operation not permitted] messages expected or incidental here, or can they be fatal? Without a completion callback before manual interruption, which supported progress signals or diagnostics distinguish slow valid progress, a stall, and a failure that did not surface through the callback? Is an ad hoc signed arm64 launcher with only com.apple.security.virtualization sufficient when Virtualization APIs initialize and the configuration validates? Is there any documented additional requirement for signing identity, entitlement, hardened runtime, installation-service access, host security, restore-image compatibility, auxiliary storage, or VM hardware configuration in this path? I am seeking interpretation of this one interrupted attempt, not asserting a framework defect or a cause for the non-completion.

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.

I am using Virtualization framework for running Golden Gate VM in swift ui window with VZVirtualMachineView. i have set the automaticallyReconfiguresDisplay to true. but when i resize the window the resolution of Golden Gate does not change automatically to fit the window. This works fine for Tahoe. Golden Gate is not respecting the automaticallyReconfiguresDisplay. Any help in fixing this bug would be very helpful to me. Thanks in advance

SANITISED SUPPORTED MACOS CAPTURE API INQUIRY REVIEW CORRECTIONS APPLIED — DRAFT, NOT SENT Question ID: MACOS-PROTECTED-CAPTURE-PROVIDER-20261004-02 Purpose: identify supported public capabilities; no project acceptance or native-execution approval is requested. Is there a supported public API combination on Apple silicon for capturing unchanged Apple-signed clang, ld and codesign inside a macOS guest after authenticated loader bootstrap but before any initializer, resolver or other target code? Only individually authenticated and explicitly enumerated loader-bootstrap operations may execute before capture; no blanket system-library exemption is assumed. The required observer/enforcer must remain outside tested guest-root authority. Include compromise of the submitting host's administrator. Observation, enforcement, state, custody, revocation and expected admission pins must not rely solely on controls that administrator can forge, replace or recover; remote signing or storage of its assertions is insufficient. The barrier must bind the exact process and guest generation, stop all target threads and byte/mapping writers, and capture complete actual loaded images, shared-cache membership, mappings, segment/private relocated bytes and backing identities coherently. Absent, crashed or disconnected observers, failed captures and missing verified release must keep execution blocked or terminate it before forbidden instructions. Release must be evidence-verified, same-incarnation and one-use. Guest termination must integrate with closed admission and generation fencing against saved-state resume, clone and replay. Our previously supplied context is macOS 26.6.2/SDK 26.5, observed but unattested. We have not run native qualification. Please state required host/guest versions explicitly; an upgrade is not assumed. Current public component documentation establishes: ES_EVENT_TYPE_AUTH_EXEC is an image-execution authorization event. es_set_deadline_miss_mode with ES_DEADLINE_MISS_MODE_FAIL_CLOSED (setter introduced in macOS 27) covers missed authorization deadlines and full-queue drops. Does this also cover client crash, deletion, disconnect or unsubscription, and could any such combination enforce the required post-loader barrier? VZVirtualMachine.pause provides VM lifecycle pausing; stop provides destructive stop with completion/error reporting. VZGuestMemoryMapping (macOS 27) exposes DRAM ranges through custom Virtio devices; the overview describes Linux guests. Is supported macOS guest use available for this purpose, and what coherent-capture/other-writer guarantees exist? Please identify the exact supported symbols and deployment configuration, documented pre-entry ordering and failure guarantees, supported macOS guest applicability, and required entitlements/signing policy. Also state whether protection weakening, target re-signing or changed system components would be required. Such requirements are compatibility limitations, not permission to perform those changes. If the full capability is unsupported, identify the specific missing public interface or guarantee rather than proposing an unsupported workaround. Public references: https://developer.apple.com/documentation/endpointsecurity/es_event_type_auth_exec https://developer.apple.com/documentation/endpointsecurity/es_set_deadline_miss_mode(::) https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_closed https://developer.apple.com/documentation/virtualization/vzvirtualmachine/pause() https://developer.apple.com/documentation/virtualization/vzvirtualmachine/stop(completionhandler:) https://developer.apple.com/documentation/virtualization/vzguestmemorymapping https://developer.apple.com/videos/play/wwdc2026/224/ Only this sanitised text and its public references are intended for relay. No private artifacts, personal/host identifiers, credentials or logs are needed. A provider reply is capability evidence; implementation, actual bindings, independent qualification, Founder acceptance and activation remain separate.

Hi, we're only seeing 15.6.1 IPSW available for VMs. Where can we find latest and secure versions of macOS IPSW on https://updates.cdn-apple.com/*/fullrestores/ ? Is there an official list somewhere that Apple provides? We need to be sure we can create the latest 15.7.7 VMs with automation and not rely on inner VM upgrades of MacOS.

I am evaluating a disposable Linux VM for bounded local test execution on an Apple Silicon Mac running macOS 15.7.9. Before integrating it, I need to establish the supported VM lifetime and termination-observation contract when its native owner fails. The synthetic configuration is intentionally small: VZLinuxBootLoader, two vCPUs, 512 MiB RAM, one serial port, and no storage, network, shared directories or socket devices. The native owner creates the VZVirtualMachine and invokes the forced stop(completionHandler:) API on its designated queue. With that owner alive and responsive, our recorded checks obtain a successful stop completion and the stopped state on the original VM object. We have also checked controller/watchdog/collector loss and a fixed, recoverable owner-queue delay. Those checks do not cover actual native-owner death or a permanent stall. The intended failure behavior is to reject all candidate output and block further attempts whenever termination is unconfirmed. We also need a supported way to end the original VM's execution; simply retaining a blocked record is not a termination mechanism. Could you clarify these points for macOS 15.7.9, including any minimum-version differences? If the process that created a VZVirtualMachine crashes or is forcibly terminated, what public contract covers cessation of every associated vCPU and any out-of-process VM/device execution? Is teardown guaranteed, and what can another trusted process observe to confirm completion for that exact VM? If that owner remains alive but is permanently suspended, deadlocked or cannot service its VZ queue, is there a supported external operation to stop that exact VM and receive an authoritative completion result? What privileges or entitlements are required? Would hosting the owner in an XPC service provide a supported VM-level lifetime guarantee when the initiating app exits? How would a surviving or later controller establish the same VM's terminal state? I understand that service termination by itself may be a different observation from VM teardown. If Virtualization.framework cannot provide this contract, does direct Hypervisor.framework document abrupt host-task teardown of every associated vCPU/VM and a supported external completion observation? Process/thread resource mapping alone leaves that question unresolved for this design. For context, the Apple DTS answer at https://developer.apple.com/forums/thread/845944 distinguishes XPC service lifetime from LaunchAgent lifetime and explains the absence of a launchd wall-clock limit. I am asking specifically about the VM lifetime and observable completion condition, rather than adding another application timer. We do not treat PID disappearance, successful signal delivery, guest silence, journal EOF, or the initial stopped state of a new VM object as proof that the original VM has ended. We have not run a real owner-kill experiment while the recovery and observation contract is unresolved. A reference to the supported API/OS guarantee, or confirmation that this combination is not supported, would help us choose the architecture. This is a contract question, not a report of a demonstrated Apple VM teardown bug.

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.

The language in the new EULA seems to indicate we can get permission to run more than 2 VMs on a single host. "(iii) except as otherwise provided in writing, signed, or issued by an authorized representative of Apple, to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use." This is important because we often have use-cases that require running docker containers and other Virtualization tools along-side of two VMs on the host and obviously cant. What's the steps we can take to get written permission for this? Thank you!

I'm using the macOS 26 vmnet network API with Virtualization framework (vmnet_network_create + VZVmnetNetworkDeviceAttachment) and giving each VM a stable address with vmnet_network_configuration_add_dhcp_reservation, plus creation-time rules from vmnet_network_configuration_add_port_forwarding_rule. Both work on the network's first run. But if the network's last interface leaves while I still hold the vmnet_network_ref, then the next interface start brings the network back without its reservations or forwarding rules. The subnet and gateway are kept. How it shows up in practice: a VM that is the only guest on its network gets restarted from inside the guest. Virtualization framework removes and re-adds the VM's vmnet interface about 1 s apart, with no delegate callback. That's enough to stop and restart the network, and the guest comes back on a dynamic lease with its forwarded ports refused. Minimal repro, no VM needed: Create a configuration in VMNET_SHARED_MODE with set_ipv4_subnet, one add_dhcp_reservation and one add_port_forwarding_rule, then call vmnet_network_create. vmnet_interface_start_with_network. InternetSharing logs port forwarding enabled …, and /etc/bootptab contains the reservation. vmnet_stop_interface. InternetSharing logs no internal interface left, stopping network → reset to idle, and /etc/bootptab is emptied. vmnet_interface_start_with_network again on the same, still-retained ref. InternetSharing logs has been started with no port forwarding enabled line, and /etc/bootptab is never rewritten. The forwarded port is refused. Control: release the ref, call vmnet_network_create again from the same configuration, and start an interface. The reservation and the rule are both back. Reproduced on macOS 27.0 (26A428) and (with a minimal vmnet only test, no actual VM) on macOS 26.6.2 (25G83). This seems to contradict the documentation for vmnet_network_create: "The lifetime of such reservation is the same as that of vmnet_network_ref." A related issue: vmnet_interface_add_ip_port_forwarding_rule and its remove and get counterparts return VMNET_FAILURE synchronously on an interface started with vmnet_interface_start_with_network. The same calls work on a vmnet_start_interface interface. The add_port_forwarding_rule documentation points to those calls for managing rules after start, so there's no way to put a rule back after the restart. The same "torn down on last detach while the ref lives on" lifecycle is also reported in apple/container#2051 (https://github.com/apple/container/issues/2051), with a different symptom (two networks sharing a bridge, so tearing one down breaks the other's egress). It proposes the same mitigation: an anchor interface held with vmnet_interface_start_with_network. Filed as: FB24895271: reservations and rules discarded when the last interface is removed FB24895264: the runtime forwarding calls fail on network-attached interfaces FB24895282: suggestion for a network state-change callback and a DHCP lease query by MAC Questions: Is losing reservations and rules when the network goes idle intended? Is holding an app-owned interface on the network (via vmnet_interface_start_with_network) so it never reaches zero interfaces a supported workaround, or does it risk other side effects?