More context: We initially thought it was the VM booting up from the image that was the cause as putting a sleep of 30 seconds between start and then when we do the open of the image eliminates the delay. However, next time we start the VM (not re-cloning) there is no delay while it's booting. This makes me suspect that there is some sort of security scan happening that's locking open up for us. But what exactly...

Running a test comparing the overhead between regular open and what we do in anka: ❯ ./run.sh Creating sparse APFS image with hdiutil (2048 MiB cap, volume BenchAPFS) → /Users/nathanpierce/apfs-open-repro/disk.dmg created: /Users/nathanpierce/apfs-open-repro/disk.dmg.sparseimage Note: hdiutil wrote /Users/nathanpierce/apfs-open-repro/disk.dmg.sparseimage (-type SPARSE uses .sparseimage beside the requested name). Done. Image stats: -rw-r--r-- 1 nathanpierce staff 10M May 14 13:55 /Users/nathanpierce/apfs-open-repro/disk.dmg.sparseimage clonefile(2): /Users/nathanpierce/apfs-open-repro/disk.dmg.sparseimage → /Users/nathanpierce/apfs-open-repro/disk_clone.dmg Clone stats: -rw-r--r-- 1 nathanpierce staff 10M May 14 13:55 /Users/nathanpierce/apfs-open-repro/disk_clone.dmg ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Original sparse image ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ === Phase 1: bare open(2) / close (baseline) === Bench: ./bench_open /Users/nathanpierce/apfs-open-repro/disk.dmg.sparseimage 12 opening /Users/nathanpierce/apfs-open-repro/disk.dmg.sparseimage for 12 consecutive open/close rounds iteration 01 open() 0.011 ms (fd=3) iteration 02 open() 0.009 ms (fd=3) iteration 03 open() 0.009 ms (fd=3) iteration 04 open() 0.008 ms (fd=3) iteration 05 open() 0.008 ms (fd=3) iteration 06 open() 0.008 ms (fd=3) iteration 07 open() 0.008 ms (fd=3) iteration 08 open() 0.008 ms (fd=3) iteration 09 open() 0.008 ms (fd=3) iteration 10 open() 0.008 ms (fd=3) iteration 11 open() 0.008 ms (fd=3) iteration 12 open() 0.008 ms (fd=3) Phase 2: attached /dev/disk21 (read-only) — GPT/NXSB use decoded sectors (UDIF-safe). === Phase 2: Anka-style stack (vdsk_native fcntls + fstat [+DKIOC] + GPT + NXSB) === Bench: ./bench_anka_style_open /dev/disk21 12 iteration 01 anka-style 2.451 ms (open+fcntl 1.332 ms, ioctl yes, gpt+nxsb skip/err) iteration 02 anka-style 0.554 ms (open+fcntl 0.047 ms, ioctl yes, gpt+nxsb skip/err) iteration 03 anka-style 0.977 ms (open+fcntl 0.496 ms, ioctl yes, gpt+nxsb skip/err) iteration 04 anka-style 1.040 ms (open+fcntl 0.364 ms, ioctl yes, gpt+nxsb skip/err) iteration 05 anka-style 1.485 ms (open+fcntl 1.395 ms, ioctl yes, gpt+nxsb skip/err) iteration 06 anka-style 1.577 ms (open+fcntl 0.645 ms, ioctl yes, gpt+nxsb skip/err) iteration 07 anka-style 1.381 ms (open+fcntl 1.020 ms, ioctl yes, gpt+nxsb skip/err) iteration 08 anka-style 2.357 ms (open+fcntl 1.508 ms, ioctl yes, gpt+nxsb skip/err) iteration 09 anka-style 0.500 ms (open+fcntl 0.069 ms, ioctl yes, gpt+nxsb skip/err) iteration 10 anka-style 1.413 ms (open+fcntl 0.722 ms, ioctl yes, gpt+nxsb skip/err) iteration 11 anka-style 0.195 ms (open+fcntl 0.061 ms, ioctl yes, gpt+nxsb skip/err) iteration 12 anka-style 0.653 ms (open+fcntl 0.099 ms, ioctl yes, gpt+nxsb skip/err) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ clonefile(2) copy ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ === Phase 1: bare open(2) / close (baseline) === Bench: ./bench_open /Users/nathanpierce/apfs-open-repro/disk_clone.dmg 12 opening /Users/nathanpierce/apfs-open-repro/disk_clone.dmg for 12 consecutive open/close rounds iteration 01 open() 0.024 ms (fd=3) iteration 02 open() 0.011 ms (fd=3) iteration 03 open() 0.009 ms (fd=3) iteration 04 open() 0.010 ms (fd=3) iteration 05 open() 0.010 ms (fd=3) iteration 06 open() 0.009 ms (fd=3) iteration 07 open() 0.009 ms (fd=3) iteration 08 open() 0.009 ms (fd=3) iteration 09 open() 0.009 ms (fd=3) iteration 10 open() 0.008 ms (fd=3) iteration 11 open() 0.008 ms (fd=3) iteration 12 open() 0.008 ms (fd=3) Phase 2: attached /dev/disk21 (read-only) — GPT/NXSB use decoded sectors (UDIF-safe). === Phase 2: Anka-style stack (vdsk_native fcntls + fstat [+DKIOC] + GPT + NXSB) === Bench: ./bench_anka_style_open /dev/disk21 12 iteration 01 anka-style 3.146 ms (open+fcntl 1.300 ms, ioctl yes, gpt+nxsb skip/err) iteration 02 anka-style 1.596 ms (open+fcntl 0.693 ms, ioctl yes, gpt+nxsb skip/err) iteration 03 anka-style 1.148 ms (open+fcntl 0.607 ms, ioctl yes, gpt+nxsb skip/err) iteration 04 anka-style 1.357 ms (open+fcntl 0.377 ms, ioctl yes, gpt+nxsb skip/err) iteration 05 anka-style 0.994 ms (open+fcntl 0.680 ms, ioctl yes, gpt+nxsb skip/err) iteration 06 anka-style 1.132 ms (open+fcntl 0.669 ms, ioctl yes, gpt+nxsb skip/err) iteration 07 anka-style 0.087 ms (open+fcntl 0.032 ms, ioctl yes, gpt+nxsb skip/err) iteration 08 anka-style 2.194 ms (open+fcntl 0.454 ms, ioctl yes, gpt+nxsb skip/err) iteration 09 anka-style 1.149 ms (open+fcntl 0.334 ms, ioctl yes, gpt+nxsb skip/err) iteration 10 anka-style 0.087 ms (open+fcntl 0.034 ms, ioctl yes, gpt+nxsb skip/err) iteration 11 anka-style 1.940 ms (open+fcntl 0.884 ms, ioctl yes, gpt+nxsb skip/err) iteration 12 anka-style 1.635 ms (open+fcntl 1.567 ms, ioctl yes, gpt+nxsb skip/err) So we do see that each time we call open it's delayed for some reason, no matter if we're doing anything special. Interesting that the clonefile() produced image does actually cause a bit more delay

I created a simple app that simulates creating a new APFS IMAGE and then tests the performance of open calls and I see, while not major delays, similar delay on the first call consistently iteration 01 open() 0.017 ms (fd=3) iteration 02 open() 0.010 ms (fd=3) iteration 03 open() 0.009 ms (fd=3) iteration 04 open() 0.009 ms (fd=3) iteration 05 open() 0.009 ms (fd=3) iteration 06 open() 0.009 ms (fd=3) iteration 07 open() 0.008 ms (fd=3) iteration 08 open() 0.009 ms (fd=3) iteration 09 open() 0.008 ms (fd=3) iteration 10 open() 0.009 ms (fd=3) iteration 11 open() 0.008 ms (fd=3) iteration 12 open() 0.008 ms (fd=3)

Hey @noam , at the moment I'm not sure you can get past the requirement to do Allow Always for new certs. I do this in the first base Template we create others from so I only do it once. Every other VM template you clone from the base has the approval in it. Hit us up in our slack if you want to further discuss solutions for this. But it would be good to know if there are commands to automate this without needing a human to click the button after first code signature/sign attempt with the cert.

I see the problem is now gone in 26.5RC for Anka VMs. @gumowemaslo , make sure you're using https://updates.cdn-apple.com/2026SpringFCS/fullrestores/122-58869/DFB1CEEF-5619-4591-9924-E20DB2C8FED0/UniversalMac_26.5_25F71_Restore.ipsw I can't speak for UTM... But maybe try Anka.

FB22685324

Is the problem dependent solely on the version of the guest? For example, if you try macOS 26.4 host with macOS 26.5 beta guest, do you still see the problem? Correct, we test al versions back to 12.x and we only see this with 26.5 so far. Does this only affect your VM product? Or can you reproduce it with other common Virtualization-based apps? I just tried another tool and the same thing happens.

https://feedbackassistant.apple.com/feedback/22649912

Oh, I closed out that suggestion I opened soon after opening it. Thanks for opening your own for the docs thing! I want to first thank you for helping us multiple times now. You're wonderful to work with. So thanks! Second, I didn't ignore what you wrote, I simply just don't ultimately need documentation. I wanted this to work without an active logged in user. There are hundreds of things over the years that aren't documented in the official docs so I've learned to just not expect much from Apple's docs and collect them through experimentation or the mac admin community postings. Worse, even if you added these docs, I couldn't trust that it would be updated or current. This is not to offend or anything, and maybe I'm wrong here and things have changed, for sure, but I just wanted to express the general mindset I and many others in the macOS space have towards documentation. Thanks again!!

AHA, fixed. I had to do these on the host. Something was wrong with the host's password I guess :shrug: sysadminctl -oldPassword "${PW}" -newPassword "${PW}" security unlock-keychain -p "${PW}" ~/Library/Keychains/login.keychain-db

Opened FB22523292 as suggestion

Ok, sorry about this. I just tried manually and it looks like the error message on a 15.x host is different and wasn't being caught on our end. Does not look like a regression anymore. And this is using unlock-keychain too. I need to dig a bit more on my end. It's unclear to me how this has been working on AWS EC2 Mac since they don't have a logged in user to the GUI.

Hmm, yeah, I tried the unlock method already. That was a solution at some point according to google, but honestly I've never had to use it. I tried and the error is still: Thu Apr 16 10:07:11 40 5a27c75d-0a35-4aeb-9ec1-e77e77f66210.log (ankahv) 578: 5a27c75d-0a35-4aeb-9ec1-e77e77f66210: failed to start: Error Domain=VZErrorDomain Code=-9 "The virtual machine encountered a security error." UserInfo={NSLocalizedFailure=Unable to access security information., NSLocalizedFailureReason=The virtual machine encountered a security error., NSUnderlyingError=0x8df12c450 {Error Domain=NSPOSIXErrorDomain Code=22 "Invalid argument" UserInfo={NSLocalizedFailureReason=Failed to get current host key., NSUnderlyingError=0x8df12c030 {Error Domain=NSPOSIXErrorDomain Code=22 "Invalid argument" UserInfo={NSLocalizedFailureReason=Failed to create new HostKey., NSUnderlyingError=0x8df12c090 {Error Domain=NSPOSIXErrorDomain Code=22 "Invalid argument" UserInfo=0x8decadd40 (not displayed)}}}}}} My concern is that this was fine and worked without issue, leading me to believe this is a regression not an enhancement request. We only started seeing this fail when we upgraded to 26.4.1 host OS. Are there any other logs or tests I can run to help clarify this for the team?

To further clarify: Unless autologin is enabled or we sign in to the GUI/VNC with a user, we can't do much of anything with macOS VMs.

No log in to the GUI at all, then run the tests.