I'm working with a MacMini M1 running Sequoia 15.1 OS, and I've configured a Virtual Machine on this device using the Virtualization.Framework to operate with the same OS version. While I can sign into my account through System Settings without any problems, I encounter difficulties when trying to add my account to Xcode 16.2. Initially, the login appears to succeed, but Xcode quickly presents a "Decoding Error": There was an issue decoding the response: (HTTP 401, 60 bytes) The data couldn’t be read because it is not in the correct format. As a result, I'm unable to access any account details or team information. I found a similar issue but I don't think it was resolved, even if it's marked as such: https://developer.apple.com/forums/thread/767673 Is there an existing workaround?

Hi, please see detailed findings on: https://github.com/utmapp/UTM/discussions/6799 basically apps that runned via Rosetta Linux now fail in kernels>=6.11 like the included in Ubuntu 24.10 with: /media/rosetta/rosetta hello assertion failed [hash_table != nullptr]: Failed to find vdso DT_HASH (Vdso.cpp:78 get_vdso_dynamic_data) Trace/breakpoint trap the issue seems to be due to this commit. https://github.com/torvalds/linux/commit/48f6430505c0b0498ee9020ce3cf9558b1caaaeb

Hello! I am wondering about the status of Nested Hyper-V Support for VM's? This is specifically regarding this issue with Parallels Desktop, which claims the issue is on Apple's side: Parallels Article: https://kb.parallels.com/en/116239 Within the Article, the no longer accessible previous Apple discussion post for this issue (at least I cannot access it): https://discussions.apple.com/thread/255546412 Is this something that will be fixed and supported soon? Thank you! (If this should be posted somewhere else please just let me know where!)

Hi, It seems that on M4 devices any virtual machine with macOS version older than 13.4 fail to boot, they stuck with a black screen. This is regardless of the virtualization software used (UTM, VirtualBuddy, Viable, etc...). After talking to many people everyone experiences the same. At least for me, this is a massive limitation of the platform, I really hope this is a bug which can be fixed. Thanks, Csaba

The VM gets a NAT IP just fine, but it doesn't have access through the proxy so I'm guessing 15.x macOS setup has a bug where it can't break out of a loop trying to phone home back to macOS. FBID: FB15689777 This is not an issue for 14.x VMs. It's also seen across different Virtualization tools.

We're creating macOS VMs on both 15.x and 14.x hosts and only the 14.x created VMs can run on both 15 and 14 hosts. If we create the VMs on 15.x, something is done by Virtualization that prevents it from running on 14.x. We've tried digging in and don't see anything that our code is doing that's special. What is Apple doing to the VMs created on 15.x hosts that's special here?

https://feedbackassistant.apple.com/feedback/15645457 Metal passthrough on intel VMs causes com.apple.screensharing.menuextra to crash and screensharing to exit Create a 15.1 VM with metal passthrough on 15.0.1 or 15.1 host, enable Screen Sharing, then try connecting to with VNC after restarting the machine. I'm using Anka to create the VM. You'll see VNC work (open vnc://192.168.64.3:5900), then a few seconds in show "Reconnecting...", then work, then go to "Reconnecting..." for ~5m until it eventually works consistently. You'll see launchd showing exits/failures (see screenshots) You'll see diagnostic reports showing things like: Thread 0 Crashed:: Dispatch queue: com.apple.RenderBox.Encoder 0 libsystem_kernel.dylib 0x7ff801da5b52 __pthread_kill + 10 1 libsystem_pthread.dylib 0x7ff801ddff85 pthread_kill + 262 2 libsystem_c.dylib 0x7ff801d00b19 abort + 126 3 libsystem_c.dylib 0x7ff801cffddc __assert_rtn + 314 4 Metal 0x7ff80d045d72 MTLReportFailure.cold.1 + 41 5 Metal 0x7ff80d01fa2a MTLReportFailure + 513 6 Metal 0x7ff80cfb74e0 +[MTLLoader sliceIDForDevice:legacyDriverVersion:airntDriverVersion:] + 200 7 Metal 0x7ff80cf265c9 +[_MTLBinaryArchive(MTLBinaryArchiveInternal) deserializeBinaryArchiveHeader:fileData:device:] + 89 8 Metal 0x7ff80cf10f0c -[_MTLBinaryArchive loadFromURL:error:] + 537 9 Metal 0x7ff80cf10288 -[_MTLBinaryArchive initWithOptions:device:url:error:] + 844 10 RenderBox 0x7ff9041a15fd RB::(anonymous namespace)::load_library_archive(NSBundle*,

I have a MacMini M2 machine running Sequoia 15.1 OS. On this machine, I am running a Virtual Machine, utilizing the Virtualization.Framework, with the same OS version, 15.1. Logging into my account in the System Settings is successful. Next, I need to add my account in Xcode 16.1. While the initial login is successful, Xcode immediately displays the following error: Decoding Error. There was a failure decoding response: (HTTP 401, 60 bytes) The data couldn’t be read because it isn’t in the correct format. As a result, I cannot see any account information, teams, etc. A very similar bug has been reported at this issue - https://developer.apple.com/forums/thread/759877, but there has been no progress or updates there. Is there any chance to fix this and get it working?

I'm trying to send various user input events to a virtual machine. The app is built in SwiftUI, so the VZVirtualMachineView is part of a view controller wrapped in NSViewControllerRepresentable. Non-modified keystrokes and mouse clicks work fine, but I can't send modified keystrokes (e.g., ⌘F). These come through without the modifier (e.g., plain F). I also haven't been able to get mouse scroll wheel events to do anything in the VM. I installed a local event monitor with addLocalMonitorForEvents(matching:handler:). Before the VM boots and the VM view exists, typing myself generates events that I see with the monitor. After the VM boots, though, the monitor does not see any of my keystrokes. The monitor never sees any of my programmatically generated events. I am sending these all through NSWindow.sendEvent(_:). Is there anything special about VZVirtualMachineView that might affect how it handles injected events? It's obvious possible (likely) that I'm doing something wrong with how I build and/or send these events into the application. Can anyone point me to documentation or examples that aren't easily found through search engines?

I have created an Apple silicon macOS Sequoia VM using UTM on my Mac also running macOS Sequoia. As noted in the documentation, I can now sign-in to iCloud in the VM. I want to update the VM to macOS Sequoia 15.1 beta. (I understand that Apple Intelligence won't be available in the VM. I need to test my software.) However, when I go to Software Update in the System Settings, I am not offered the opportunity to enroll in the beta. (The "Beta Updates" section never appears.) Is this intentional?

We are currently utilizing VZ with Lima (details: Lima VM and VZ) for our development environment. However, we're encountering a critical issue with the com.apple.Virtualization.VirtualMachine process leading to open file handle exhaustion. When mounting our programming languages dependency cache folder (Which can have a lot of files) into the VZ VM, we encounter an operating system error related to open file limits: /gomodcache/github.com/go-git/go-git/v5@v5.4.2/plumbing/object/patch.go:14:2: open /gomodcache/github.com/go-git/go-git/v5@v5.4.2/plumbing/format/diff/unified_encoder.go: too many open files in system Further investigation revealed an abnormally high number of open files associated with the com.apple.Virtualization.VirtualMachine process. A significant portion of these files are not actively used but remain open. Example Case: A file (/Users/rcurrah/test.txt) created on the Mac host and listed (ls) in the VM remains open even 20 minutes later, as evidenced by the following command output: ❯ lsof | grep 11208 | grep test.txt COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME com.apple 11208 rcurrah 4823r REG 1,13 0 46200882 /Users/rcurrah/test.txt Steps to Reproduce the Issue: To reproduce the file handle exhaustion follow the below steps. This process will create a large number of files on the Mac host, listing them on the VZ VM, and then verifying their open status using lsof. Setup the VZ Environment with Sharing: Create a VZ VM with your home directory shared to the VM. Create a Test Directory on the Mac Host: Create a new directory on your Mac host, e.g., mkdir ~/test-file-exhaustion. Generate a Large Number of Files: Navigate to the created directory: cd ~/test-file-exhaustion. Use a loop to create a large number of files, e.g., for i in {1..10000}; do touch "file_${i}.txt"; done. This will create 10,000 files named file_1.txt, file_2.txt, etc. List Files in the VM: Access the VZ VM shell. Navigate to the mounted directory and list the files using the ls command, e.g., ls /path/to/mounted/test-file-exhaustion. Check Open Files on Mac Host: Exit the VM and return to your Mac host terminal. Use the lsof command to check for open files related to the com.apple.Virtualization.VirtualMachine process: lsof | grep "$(pgrep com.apple.Virtualization.VirtualMachine)" | grep 'test-file-exhaustion' | wc -l. Document the Output: Record the output of the lsof command. Note the number of open files. Verify File Closure (or Lack Thereof): After a certain period, e.g., 20 minutes, repeat the lsof command to see if the files are still open, indicating that they haven’t been closed properly by the process. Given these observations, we have a couple of questions: Is this behavior of com.apple.Virtualization.VirtualMachine retaining open file handles a known issue or a bug? Should VZ be managing the closure of these file handles more efficiently, especially when they are no longer in use? This issue is impacting our development workflow significantly. Any guidance or insights on resolving this would be highly appreciated. Thank you for your attention to this matter. Best regards, Ryan

hello developers, First priority I couldn't find a proper title for the question :( The reason why I open a topic here is not to find the answer by direct point shooting; My goal is what do Apple, Developer, Companies and Devops teams think and comments about the subject I'm going to ask here? We use Jenkins as the Devops CI/CD tool at our company, and in Macos/Apple/iOS development, we use a lot of Mac Mini devices. Since we build/compilers on a project-based, version-based basis, we cannot get 100% efficiency from our devices. (For example, because the dependencies of a project are different from other projects; we dedicate only 1 Mac Mini to that project. (As the dependecys of the projects are too many and large, the migration process is very difficult for us, the cost of moving to a lower-level Mac Mini device is high / but this is just an example)) While researching, I saw that there is no docker container image for MacOs X (enterprise or legal) and I know about the Apple EULA. (For virtualization, Apple hardware must be used as a basis. Because the MacOs system is paid for on a device-based basis.) What I want to ask here is can I find or create a MacOs docker container image legally? How is the structure of other companies in their CI processes? If I install MacOs with more than one VMware/VirtualBox on Mac Mini, What harm could it do me in Jenkins? (I'm curious about people's comments on this.)

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)