Reject macOS balloon and document native VZ overcommit - #1
Draft
kaaanata wants to merge 9 commits into
Draft
Conversation
Add a per-VM "memoryBalloon" setting (disabled by default) that, when enabled via "tart set <name> --memory-balloon true", attaches a VZVirtioTraditionalMemoryBalloonDeviceConfiguration to the VM, allowing supported guest operating systems to participate in best-effort memory reclaim. A balloon target can be requested at run time via "tart run --balloon-target-memory <MB>". The target is re-applied periodically, since a target set before the guest's virtio-balloon driver probes the device is lost when the guest resets the device while booting (the same applies to guest reboots). The balloon device is skipped for suspendable VMs (similarly to the entropy device) to not interfere with the save/restore support. VM.craftConfiguration() is split into a buildConfiguration() part and a validation part, so that the device wiring can be unit-tested without the "com.apple.security.virtualization" entitlement. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
For macOS guests, "tart run --balloon-target-memory" now also enforces the VM's own minimum supported memory size (dictated by the restore image), similarly to how "tart set --memory" restricts the configured memory size. Addresses a PR review comment. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…emory Reworks the feature per the PR feedback[1]: instead of an opt-in device plus a target size that has to be picked up front, Linux guests now get a virtio memory balloon device out of the box and the "Control" menu gained a "Free Up Memory" toggle that asks the guest to shrink as much as it can. * the "memoryBalloon" setting and "tart set --memory-balloon" are gone: the device is attached whenever the guest is Linux (macOS guests show little to no practical memory reduction) and the VM is not suspendable (similarly to the entropy device, to not interfere with the save/restore support) * "tart run --balloon-target-memory" is gone too, replaced by the menu item, which sets the balloon target to the smallest size Virtualization.Framework accepts and keeps re-applying it every 15 seconds, since a target is lost when the guest's virtio-balloon driver resets the device while booting (the same applies to guest reboots). Toggling it off deflates the balloon and gives the memory back to the guest * fixes the craftConfiguration()/buildConfiguration() split to take a VMDirectory instead of a disk URL, which stopped compiling after the stacked disk support landed in 16d186c [1]: openai#1276 (comment) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
kaaanata
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This draft records the rejected Offloop macOS memory-balloon experiment on top of upstream Tart 2.36.0. It must not merge or ship.
The experiment found two terminal incompatibilities:
AppleVirtIOBalloon, but Virtio PFNs use 4 KiB units while arm64 macOS uses 16 KiB VM pages. A 16 GiB guest given a 15 GiB framework target wired about 4.25 GiB, rising from 60,893 to 339,403 wired pages. A delayed one-shot 12 GiB target made SSH unreachable, and restoring 16 GiB did not deflate it.phys_footprintincreased from 17,065,632,608 to 17,165,247,352 bytes at the 15 GiB target. The guest surrendered memory while the host helper retained its charge.Private API research also rejected
_memoryOvercommitmentAllowed. On macOS 26.6.2 the selector raised configuration validation from the public 64 GiB limit to a reported 1,030,400 MiB, but a 66 GiB VM failed at start. Even an otherwise-valid 40 GiB VM failed when the private overcommit and pressure-termination booleans were set. The private implementation was removed from the fork.The supported replacement needs no fork. Upstream Tart 2.35.0 started two ordinary 40 GiB Tahoe/Xcode guests on the 64 GiB McIntosh host, creating an 80 GiB aggregate configured maximum. Both guests retained authenticated SSH and concurrently completed the Xcode 26.5 iPhone 17 Pro Simulator canary. At completion the host compressor held about 23.44 GiB, swap remained 12.19 MiB, cumulative swapouts did not advance, and cleanup left only the pinned OCI source image.
Virtualization.framework therefore already supplies aggregate soft overcommit: VM maxima may exceed host physical memory in aggregate while macOS compresses and pages actual resident working sets. It does not expose cgroup-like per-VM current memory or a host-triggered reclaim receipt. Production keeps upstream Tart, two admitted jobs, and a 16 GiB per-VM maximum on hosts with at least 64 GiB; smaller hosts retain 8 GiB.
Tracking issue: #2
Initial policy MR: https://git.f.cv/intelligence/monorepo/-/merge_requests/7287
Canonical evidence MR: https://git.f.cv/intelligence/monorepo/-/merge_requests/7316
Evidence commits:
6023c21789ef49836745e66eda8b04e837fccb7ba9b0162adf2b4c66fb95c7057ff864fdfad989b1c462df930b2f00dd638ce1ede12c817b8c9a5b6416a90a2a1cb674c3935d1eff398f72751cafc590