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.