I fixed all of my issues like this by using load -w and unload -w`

From what we can tell this started happening in 13.4.1(c) on intel only.

Screenshots attached

iCloud login inside of Anka VMs work great if they are Silicon/arm. On Intel, we see This is on 15.1 host and 15.1 VM.

I can reproduce it by: Block all internet traffic to my MBP but allow all LAN Set up squid proxy on another machine on the LAN Set my http/s_proxy envs in the shell, set System Preferences > Network > ETH Proxy settings to the proper IP and port of the squid proxy. This allows me to tunnel through the squid proxy and reproduce the issue easily without a corporate proxy setup.

Lots of different requests to apple urls from the squid proxy logs and I'm not sure if they're even related or not... 1730834097.486 610093 192.168.1.79 TCP_TUNNEL/200 4681 CONNECT o22381.ingest.sentry.io:443 - HIER_DIRECT/34.120.195.249 - 1730834054.010 120115 192.168.1.79 TCP_TUNNEL/200 8605 CONNECT swdist.apple.com:443 - HIER_DIRECT/23.213.44.215 - 1730834272.626 1387 192.168.1.79 TCP_TUNNEL_ABORTED/200 14481 CONNECT weatherkit.apple.com:443 - HIER_DIRECT/23.47.52.133 - 1730834267.351 67 192.168.1.79 TCP_TUNNEL/200 22175 CONNECT init-p01md.apple.com:443 - HIER_DIRECT/23.220.102.59 - 1730834267.381 97 192.168.1.79 TCP_TUNNEL/200 16394 CONNECT init.ess.apple.com:443 - HIER_DIRECT/17.253.7.133 - 1730834309.963 42 192.168.1.79 TCP_MISS/200 256 GET http://netcts.cdn-apple.com/ - HIER_DIRECT/23.38.189.98 text/html 1730834310.772 17 192.168.1.79 TCP_MISS/200 256 GET http://netcts.cdn-apple.com/ - HIER_DIRECT/23.38.189.98 text/html 1730834344.022 117504 192.168.1.79 TCP_TUNNEL/200 49043 CONNECT developer.apple.com:443 - HIER_DIRECT/17.253.23.201 - 1730834346.178 443467 192.168.1.79 TCP_TUNNEL/200 4645 CONNECT github-partners.slack.com:443 - HIER_DIRECT/3.134.44.134 -

OK, after 15 minutes it finally allows me to go to the siri screen. Here are the logs from that time: Very odd...

Another quick note: It looks as if the length it takes to eventually timeout/proceed differs between networks. In a corporate network behind a different proxy, it cannot be worked around by waiting for 15/19minutes like I can locally. Sometimes it's double that.

Just to clarify a bit -- When running through Virtualization on Intel, it looks as if any xcrun simctl list devices --json or other simulator related command is throwing the AVPIdentity errors. This, obviously, breaks json parsing and any tool that parses it. We see the simctl errors in the Console logs too, but are unsure where they're coming from or what could be missing here to cause it. We're looking for some guidance from Apple about the issue either: how to hide the log messages, or how to prevent them from happening at all by modifying the OS in the VM. Also, this does not seem to happen on 14.x VMs, so this was something introduced in 15.x.

Bug number: FB16084148

Veertu has built Anka Virtualization to get as close as possible to Docker/containers as possible on macOS (intel and arm). You can use it to run ephemeral macOS VMs from templates of different version of macOS. We have plugins for almost all of the commonly used CI/CD platforms, like Jenkins, Github Actions, etc.

Bump, same here.

Looks like it may be fixed in 15.3 Mac-mini:~ anka$ xcrun simctl list devices --json | head { "devices" : { "com.apple.CoreSimulator.SimRuntime.iOS-18-2" : [ { "dataPath" : "\/Users\/anka\/Library\/Developer\/CoreSimulator\/Devices\/DE110594-CF92-470F-B10E-5636C4CD9EBC\/data", "dataPathSize" : 18337792, "logPath" : "\/Users\/anka\/Library\/Logs\/CoreSimulator\/DE110594-CF92-470F-B10E-5636C4CD9EBC", "udid" : "DE110594-CF92-470F-B10E-5636C4CD9EBC", "isAvailable" : true, "deviceTypeIdentifier" : "com.apple.CoreSimulator.SimDeviceType.iPhone-16-Pro",

Nevermind, I had to security unlock-keychain first

By default Anka VMs have SIP and Firewall disabled. I can reproduce on a vanilla macOS VM using the latest 16.4 Xcode, Simulators etc. I don't see any ~/Library/Logs/CoreSimulator/ logs indicating a problem there. I've generated a sysdiagnose from the VM right after reproducing the issue which should be helpful for the Apple team: https://drive.google.com/file/d/1tkbnm8bxuJwlAoAU6-0u1_v-LeQpt95D/view?usp=sharing