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 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

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?

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.

I’m using Virtualization.framework on Apple silicon with a Linux guest (VZGenericPlatformConfiguration + VZLinuxBootLoader). The VM is intentionally minimal: 2 vCPUs, 2 GiB RAM 1 virtio entropy device 2 virtio block devices (base read-only, scratch read-write) 1 virtio console with 2 ports, both isConsole = false no serial, network, sharing, socket, USB, audio, graphics, keyboard, pointing, balloon, or custom virtio devices no EFI variable store nested virtualization disabled On the normal success path the host does not call requestStop(). A destructive host stop is tracked separately and treated as failure. I need a supported way for the host to distinguish: a clean Linux guest shutdown intentionally issued by the guest after its application protocol and cleanup have completed, from an abnormal or independent shutdown path such as kernel panic, watchdog, thermal / hardware-protection shutdown, emergency shutdown, or another kernel/platform-triggered stop. guestDidStopVirtualMachine tells me that the guest stopped, but I cannot find a public contract that says which Linux/kernel/platform histories can produce that callback, nor a public shutdown reason/initiator value. My specific questions are: For VZGenericPlatformConfiguration + VZLinuxBootLoader, what is the documented complete guest-visible shutdown/reset event surface, including implicit platform events not represented by explicitly configured device arrays? What Linux-facing mechanism does VZVirtualMachine.requestStop() use in this configuration? Can guestDidStopVirtualMachine also be emitted after panic, watchdog, thermal/hardware-protection shutdown, emergency shutdown, or another guest-kernel/platform shutdown source? Are those abnormal cases guaranteed to arrive through virtualMachine(_:didStopWithError:) instead? If guestDidStopVirtualMachine can represent multiple terminal histories, is there any supported public API or documented guarantee that lets the host distinguish a clean guest system-off from the abnormal/platform-triggered cases? If not, is it correct to treat this distinction as unspecified by the public Virtualization.framework contract? I do not need private implementation details. A public/supported contract describing which terminal histories can produce each delegate callback would be enough. This matters because the host is fail-closed: it must accept PASS only after an application-level success condition and a clean guest shutdown. A successful runtime observation alone is not enough for the qualification. Environment: Apple silicon / arm64 macOS 26.6.2 (25G83) public Virtualization.framework APIs

Hi, I am trying to use AAUSBAccessoryManager with mac os 27 to connect host usb device to guest vm. here is my code // // USBPassthroughManager.swift // VirtualProg import AccessoryAccess import Foundation import IOKit @available(macOS 27.0, *) class USBPassthroughManager: NSObject, ObservableObject, AAUSBAccessoryListener { static let shared = USBPassthroughManager() @Published var availableDevices: [AAUSBAccessory] = [] func startListening() async { do { let existing = try await AAUSBAccessoryManager.shared .registerListener(self, matchingCriteria: []) await MainActor.run { self.availableDevices = existing } } catch { LogManager.shared.log(vmName: AppConstants.logGeneral, type: .error, message: "USB passthrough listener failed: \(error.localizedDescription)") } } func usbAccessoryDidConnect(_ usbAccessory: AAUSBAccessory) { DispatchQueue.main.async { guard !self.availableDevices.contains(where: { $0.registryID == usbAccessory.registryID }) else { return } self.availableDevices.append(usbAccessory) print(self.displayName(for: usbAccessory)) } } The usb icon in status bar menu is displayed and i can select the the usb device to connect to my app. the usb device is connected to my app. it is shown in the status bar. but usbAccessoryDidConnect is not firing. i have the entitlement com.apple.developer.accessory-access.usb in the capabilities. i get this in the xcode console start failed ((iokit/common) not permitted) for plugin for .......... and also disconnect is also not firing. Not sure what i am doing wrong. How can i determine the name of the USB Device from AAUSBAccessory. Any help would be appreciated. Thanks

Hi everyone, We're running Xcode/Swift CI builds inside macOS VMs (Tart / Apple Virtualization Framework) on a 32-core Apple Silicon host. While investigating VM build performance, we noticed a consistent pattern: assigning 24 vCPUs to the VM produces faster overall build times than assigning 26-30 vCPUs, despite the host still showing idle CPU capacity. With higher vCPU allocations, the build starts by utilizing the CPUs well, but later stages show a noticeable drop in CPU utilization and overall build throughput. In contrast, the 24-vCPU configuration maintains more stable CPU usage and completes the workload faster. This was observed repeatedly with the same Xcode/Swift workload. The result seems counterintuitive because the VM is not exhausting the available host CPU resources. Our testing identified 24 vCPUs as the current sweet spot, even though the host provides 32 physical cores. Has anyone observed similar behavior? Some questions I have: Do Xcode builds stop scaling efficiently beyond a certain vCPU count? Are there known scheduler or virtualization effects when assigning nearly all host cores to a macOS VM? Is there a commonly recommended practice to leave a number of host cores unassigned, even when the host appears mostly idle?

This post applies to Apple Virtualization framework feature to setup a user account during VM setup (VZMacGuestProvisioningOptions) introduced in macOS 27: Issue: Creating a user via VZMacGuestProvisioningOptions during VM setup, results in a user which is not returned by CSidentityQueryExecute(). Same code executed on a macOS 26 VM or a macOS 27 VM where the user was created by hand within the VM (so without VZMacGuestProvisioningOptions) returns the user. How to reproduce: Create an VM via the Apple Virtualization framework and use the VZMacGuestProvisioningOptions to create the user during VM setup. I actually used Virtual Buddy and Tart to do this. Then run the following code: internal enum MyLogger { static let info = Logger(subsystem: Bundle.main.bundleIdentifier!, category: "Utils-\(getuid())") } public struct Identity { public let posixUID: id_t public let posixName: String init?(posixUID: id_t, posixName: String) { self.posixUID = posixUID self.posixName = posixName } } class Utils { public static func userIdentities() -> [Identity] { let defaultAuthority = CSGetLocalIdentityAuthority().takeUnretainedValue() let query = CSIdentityQueryCreate(nil, kCSIdentityClassUser, defaultAuthority).takeRetainedValue() guard CSIdentityQueryExecute(query, 0, nil), let identities = CSIdentityQueryCopyResults(query).takeRetainedValue() as? [CSIdentity] else { return [] } for ident in identities { MyLogger.info.log("CSIdentity: \(ident.hashValue, privacy: .public)") } let idents = identities .compactMap { Identity( posixUID: CSIdentityGetPosixID($0), posixName: CSIdentityGetPosixName($0).takeUnretainedValue() as String ) } .sorted { $0.posixName.localizedStandardCompare($1.posixName) == .orderedAscending } for ident in idents { MyLogger.info.log("Identity: \(ident.posixName, privacy: .public), \(ident.posixUID, privacy: .public)") } return idents } } Expected behavior: The code returns the user account created via VZMacGuestProvisioningOptions. Actual behavior: I get no user account When you test the same on a macOS 27 VM where the user is created via the traditional way (Setup assistant), the app shows the account. This also applies to all additional user accounts created after VM setup via System Settings.app. The bug also still exists on a VM created with macOS 27 beta 4. Is anybody having the same issue? Is that a bug in macOS 27? I already created a Feedback for this: FB23716201

Hi, I was trying to run a macOS VM under a launchd daemon as part of a requirement. The parent daemon spawns a macOS VM under root user. Sometimes this is fine, but sometimes I'm getting a security error from VZ library : Unable to access security information. The virtual machine encountered a security error. In system logs, I was able to see this : ctkd: unable to generate key: error e00002e2 for com.apple.Virtualization.VirtualMachine with SepKey ACL I think this indicates Virtualization.framework asked CryptoTokenKit/Secure Enclave to create a key, and the security subsystem rejected it in the current execution context. Is it possible to run VM this way ? If yes, what am I missing ?

Hi all, I'm running 2 macOS VMs on a bare-metal Mac (host is also macOS). I'm seeing inconsistent iMessage sign-in behavior depending on the Apple ID type and whether it's bare metal or virtualized: Managed Apple ID (ABM-issued): signs into iMessage fine on the bare-metal host. Same Managed Apple ID: fails to sign into iMessage inside the VM on the same physical machine. Personal/basic Apple ID: signs in fine in the VM without issue. Has anyone run into this specific combination — MAID working on bare metal but not inside a VM, while a personal ID works fine in both?

I am unable to sign into my Apple account on a Golden Gate b1 VM. Thus, I'm unable to switch to the beta channel and upgrade this VM to the latest beta Golden Gate seed. The error I get is: Verification Failed An unknown error occurred. I've looked in Console.app for any clues and no luck so far. Is this a known issue and is there a workaround?

In the past I was always able to install every major macOS version on an external drive so that I can test my apps. But now I'm unable to install macOS Tahoe 26 on an external drive. Actually, as far as I'm aware, there are not even official links to macOS 26 installers, but only instructions on how to update to macOS 26 from an existing macOS installation. So I thought I'd install macOS 15 on a separate drive and then update to macOS 26, but whenever I run the macOS 15 installer, tell it to install on the external drive, and reboot after the setup process completes, my MacBook just boots into my main macOS partition as if nothing happened. 3 months ago I somehow managed to install macOS Tahoe beta 1 on an external drive, I don't remember how (but I don't think it was anything crazy); booting into that beta 1 partition and trying to update doesn't work either, as my MacBook again boots into my main macOS partition. I already asked help about the update problem one month ago here, but nobody replied. Could someone at Apple please provide instructions on how one is supposed to install macOS 26 on an external drive (if possible before it becomes available to the public)? Are we supposed to buy a separate Mac for every macOS version that we want to test our apps on?

Trying to virtualize macOS 27 on a 26.6 host failed at 77% install progress, even with Xcode 27 beta installed. But worked fine on a macOS 27 host. Are there any tricks to use a 26 host? Thanks!

When trying to update from beta 2 to beta 3 and from beta 3 to the revised beta 3 build, softwareupdate failed at the personalization step. This was because a USB-C accessory passed through to a VM via Virtualization.framework was holding the USB-C controller. This blocked I²C access to the AppleTypeCRetimer chip during the preflight personalization phase. In the unified log, this appears as: AppleTypeCRetimerIICDeviceHandle readRegister: Read result 0xe00002d5 AppleHPMLibRT13Interface: HPM is NOT in ADFU, modeData=0x20505041 [SPI] MSUParsedToleratedFailureForStep | step:update_usbcretimer → FAILURE MSUPreflightUpdate | FAILURE → "failed to copy firmware identity" 0xe00002d5 = IOKit I²C device not responding 0x20505041 = "APP " — HPM stuck in application mode, can't enter ADFU (firmware update mode) Without retimer firmware identity, the SFR installer can't complete personalization I was able to work around this by physically unplugging the passed through device (which is suboptimal for a headless server in a rack). Feedback ID: FB23772773 Hardware: Mac16,9 (Apple Silicon) Update: macOS 27 Beta 3 (26A5378j → 26A5378n), full OTA via Software Update Failure: SUMacControllerErrorPreflightPersonalizeFailed (7723) → MSU_ERR_PERSONALIZATION_FAILURE (2) → "failed to copy firmware identity" (1259)

When running a macOS virtual machine using Virtualization.framework, I am encountering a reproducible issue where the kernel’s internal VM slot counter (hv_apple_isa_vm_quota) is not decremented after a guest-initiated shutdown. This leads to subsequent VM launches failing with VZErrorVirtualMachineLimitExceeded, even though no active VMs appear to be running. Steps to Reproduce: Create a valid VZVirtualMachineConfiguration for a macOS guest Initialize and start a VZVirtualMachine instance Inside the guest macOS, perform a normal shutdown (Apple menu → Shut Down) Wait until VZVirtualMachine.state becomes .stopped Attempt to start the same VZVirtualMachine instance again Expected Behavior: The VM should restart successfully.
The kernel should release the VM slot once the guest shuts down, allowing a new VM instance to start without requiring any host-side intervention. Actual Behavior: start() fails with: Domain: VZErrorDomain Code: 6 (VZErrorVirtualMachineLimitExceeded) Description: “The number of virtual machines exceeds the limit. The maximum supported number of active virtual machines has been reached.” Despite the VM reporting .stopped, the system continues to behave as if a slot is still allocated. Workarounds Tested: The following approaches did not resolve the issue: Releasing and recreating the VZVirtualMachine instance Introducing delays (5s, 30s, 60s) before restarting Terminating all processes related to Virtualization.framework The only reliable recovery is a full macOS host reboot, which resets the VM quota state. Environment: macOS 26.5 (Tahoe) Apple Silicon: M4 Max Virtualization.framework (system-provided) Impact: This issue makes reliable VM lifecycle management difficult for applications relying on Virtualization.framework (e.g., UTM and similar tools). In automated environments (CI/CD, testing pipelines), it can cause persistent VM launch failures and require full host reboots, interrupting all workloads. Suspected Issue: It appears the kernel VM slot counter (hv_apple_isa_vm_quota) is not consistently decremented when a VM exits via guest-initiated shutdown, despite the VZVirtualMachine transitioning to .stopped. This suggests a race condition or missing cleanup path in the shutdown lifecycle handling. Request: Could you confirm whether this is a known issue or expected behavior, and whether there is a recommended API-level workaround to ensure VM slot cleanup after guest shutdown?

Filed a feedback on this: FB23038153 I am unable to install a new Sequoia 15.6.1 (latest available .ipsw) on a Tahoe 26.5.1 host using a Virtualization.framework-based VM app. I’ve tried both Tart and VirtualBuddy. Both get to 90% of the installation, then fail with this error: Error Domain=VZErrorDomain Code=10007 "Installation failed." UserInfo={NSLocalizedFailure=An error occurred during installation., NSLocalizedFailureReason=Installation failed., NSUnderlyingError=0xc2ac2e280 {Error Domain=com.apple.MobileDevice.MobileRestore Code=-1 "AMRestorePerformRestoreModeRestoreWithError failed with error: 11" UserInfo={NSLocalizedDescription=AMRestorePerformRestoreModeRestoreWithError failed with error: 11, NSLocalizedFailureReason=An unknown error occurred during installation.}}} I have tried re-installing MobileDevice.pkg from both Xcode 27 beta 1 and Xcode 26.5.0. I’ve rebooted my Mac. I get the same result each time. I’ve also tried using an older Sequoia restore image (15.4.1), same result. Installing a Tahoe guest works fine.