macOS guest freezes after update reboot on M4 host with Virtualization.framework

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

1. Cold-boot a macOS 15.7.9 guest under Virtualization.framework, as the only

VM on the host.

1. In the guest: System Settings > Software Update > install macOS 15.8.

2. 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.