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"

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.

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.

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

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.

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

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