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

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