For the full list: FB22875951

Opened FB22869718

Ultimately we didn't solve the first open delay. It's understandable that there will be a bit of a delay for the first call. But, we were seeing like 10+ seconds for a specific APFS image. It turned out after-all to be a problem with how we were reading only certain images that were created with older versions of Anka. Doesn't happen on newer images we were creating so we're going to just create and use newer ones.

Moderators, please delete this. I think we figured it out.

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

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