Describe the bug
When the OrbStack Linux VM experiences a burst of VM_FAULT_OOM events (visible in vmgr.log as pagefault_out_of_memory: N callbacks suppressed), OrbStack's LAN port-forwarding mechanism stalls. New TCP connections to LAN-exposed ports time out for 48+ seconds. Services behind NPM become unreachable to LAN clients. NPM receives no connection at all during these windows, confirming the failure is in OrbStack's forwarder, not in the application layer.
To Reproduce
vmgr.log shows VM_FAULT_OOM bursts every ~30–33 minutes. Two today were severe (pagefault_out_of_memory: 20+ callbacks suppressed). In both cases, docker.console.log confirms that OrbStack's internal DNS resolver (0.250.250.200:53) stopped answering queries for the entire duration of the stall — not just one subsystem, but port-forwarding and DNS both going unresponsive simultaneously:
Cluster 1 — 09:33 EDT kernel OOM burst, followed by:
kernel | [19372] pagefault_out_of_memory: 20 callbacks suppressed
vmgr | 09:47 failed to dial local dialAddr=192.168.10.11:61208: connection timed out
runtime | 09:46–09:57 DNS timeouts (plex, qbittorrent, proxy, ntfy, openwebui) → 0.250.250.200:53
Cluster 2 — 11:11 EDT kernel OOM burst, followed by:
kernel | [25222] VM_FAULT_OOM ×9 rapid succession
vmgr | 11:20 failed to dial local dialAddr=192.168.10.11:61208: connection timed out
runtime | 11:23–11:32 DNS timeouts (qbittorrent, nas, gitea, alertmanager) → 0.250.250.200:53
VM has 10.7 GB free out of 16 GB at rest — this is not chronic memory exhaustion. The OOM events appear to be transient balloon deflation spikes that take down multiple networking subsystems simultaneously.
Impact
All Docker services exposed via docker.expose_ports_to_lan: true become unreachable to LAN clients for the duration of the stall. The macOS host shows a correlated spike in kernel (system-mode) CPU during these events.
Expected behavior
The LAN port-forward layer should either (a) tolerate transient VM memory pressure without dropping connections, or (b) recover within a few seconds rather than holding new connections in a timed-out state for 48+ seconds.
Diagnostic report (REQUIRED)
OrbStack info:
Version: 2.2.1
Commit: 0e182b501fcd9e05b99ffb363fce03610390c400 (v2.2.1)
System info:
macOS: 26.5.1 (25F80)
CPU: amd64, 8 cores
CPU model: Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
Model: MacBookPro16,2
Memory: 32 GiB
Full report: https://orbstack.dev/_admin/diag/orbstack-diagreport_2026-06-22T19-58-03.762202Z.zip
Screenshots and additional context (optional)
No response
Describe the bug
When the OrbStack Linux VM experiences a burst of VM_FAULT_OOM events (visible in vmgr.log as pagefault_out_of_memory: N callbacks suppressed), OrbStack's LAN port-forwarding mechanism stalls. New TCP connections to LAN-exposed ports time out for 48+ seconds. Services behind NPM become unreachable to LAN clients. NPM receives no connection at all during these windows, confirming the failure is in OrbStack's forwarder, not in the application layer.
To Reproduce
vmgr.log shows VM_FAULT_OOM bursts every ~30–33 minutes. Two today were severe (pagefault_out_of_memory: 20+ callbacks suppressed). In both cases, docker.console.log confirms that OrbStack's internal DNS resolver (0.250.250.200:53) stopped answering queries for the entire duration of the stall — not just one subsystem, but port-forwarding and DNS both going unresponsive simultaneously:
Cluster 1 — 09:33 EDT kernel OOM burst, followed by:
kernel | [19372] pagefault_out_of_memory: 20 callbacks suppressed
vmgr | 09:47 failed to dial local dialAddr=192.168.10.11:61208: connection timed out
runtime | 09:46–09:57 DNS timeouts (plex, qbittorrent, proxy, ntfy, openwebui) → 0.250.250.200:53
Cluster 2 — 11:11 EDT kernel OOM burst, followed by:
kernel | [25222] VM_FAULT_OOM ×9 rapid succession
vmgr | 11:20 failed to dial local dialAddr=192.168.10.11:61208: connection timed out
runtime | 11:23–11:32 DNS timeouts (qbittorrent, nas, gitea, alertmanager) → 0.250.250.200:53
VM has 10.7 GB free out of 16 GB at rest — this is not chronic memory exhaustion. The OOM events appear to be transient balloon deflation spikes that take down multiple networking subsystems simultaneously.
Impact
All Docker services exposed via docker.expose_ports_to_lan: true become unreachable to LAN clients for the duration of the stall. The macOS host shows a correlated spike in kernel (system-mode) CPU during these events.
Expected behavior
The LAN port-forward layer should either (a) tolerate transient VM memory pressure without dropping connections, or (b) recover within a few seconds rather than holding new connections in a timed-out state for 48+ seconds.
Diagnostic report (REQUIRED)
OrbStack info:
Version: 2.2.1
Commit: 0e182b501fcd9e05b99ffb363fce03610390c400 (v2.2.1)
System info:
macOS: 26.5.1 (25F80)
CPU: amd64, 8 cores
CPU model: Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
Model: MacBookPro16,2
Memory: 32 GiB
Full report: https://orbstack.dev/_admin/diag/orbstack-diagreport_2026-06-22T19-58-03.762202Z.zip
Screenshots and additional context (optional)
No response