feat(tart): native vmnet networking via VZVmnetNetworkDeviceAttachment#1268
feat(tart): native vmnet networking via VZVmnetNetworkDeviceAttachment#1268pepicrft wants to merge 3 commits into
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cf30410395
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if octet == 64 { | ||
| octet = 65 | ||
| } | ||
| return octet |
There was a problem hiding this comment.
When a host runs two VMs whose different MAC addresses hash to the same third octet, both --net-vmnet-expose runs try to create the same 192.168.<octet>.0/24 vmnet network and reserve the same guest address, so the second vmnet_network_create fails even though Tart's MAC-collision check passed. With only 253 possible subnets this becomes likely in CI fleets or hosts that run many VMs; derive the subnet from more MAC bits or allocate/check active subnets instead of reducing to one octet.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 001cfca565
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| private static func release(_ pointer: OpaquePointer) { | ||
| Unmanaged<AnyObject>.fromOpaque(UnsafeRawPointer(pointer)).release() |
There was a problem hiding this comment.
When --net-vmnet creates a vmnet configuration/network, these refs are Swift strong references to vmnet Objective-C objects; ARC releases them when the local/property references go away. Calling Unmanaged.release() here means configuration is released once by the defer and again by ARC at the end of init, and network is released in deinit and again as the stored property is destroyed, so vmnet runs can over-release and crash during network creation or teardown. Let ARC manage these references instead of manually releasing them.
Useful? React with 👍 / 👎.
|
What is the motivation for this change? Softnet is also using vmnet under the hood and is kind of a superset of what VZVmnetNetworkDeviceAttachment provides. Plus we have much more flexability via a separate process. |
2 participants
What changed
NetworkVmnet, a Swift 6.4 gated implementation of Tart'sNetworkprotocol using vmnet logical networks andVZVmnetNetworkDeviceAttachment.--net-vmnetand--net-vmnet-exposetotart run, including validation for network mode exclusivity and the macOS 26 host requirement reported by the Xcode 27 SDK headers.--net-vmnet-exposethrough tovmnet_network_configuration_add_port_forwarding_rulefor TCP and UDP forwarding.VZVirtualMachineConfiguration.labelon macOS 27+ from the Tart VM name so framework-created system services are easier to identify.EXTERNAL_PORT:INTERNAL_PORT[/PROTOCOL]vmnet forwarding specs and label sanitization coverage for VM names.Why
Softnet provides port forwarding through an external sidecar. The newer vmnet logical network APIs let Tart configure shared networking and forwarding in process while still using the standard Virtualization network attachment flow.
While reviewing the WWDC26 Virtualization changes, the VM label API was the other low-risk improvement that fit this PR. It has no user-facing surface area and is safely gated to the Xcode 27/macOS 27 API.
Impact
Users can opt into native vmnet networking with
--net-vmnetand can forward host TCP or UDP ports to the guest with--net-vmnet-expose. The existing Softnet path remains unchanged.The vmnet implementation is gated behind
#if compiler(>=6.4)and@available(macOS 26, *), so the current Swift 6.3/Xcode 26 path still builds while Xcode 27 can type-check the new vmnet APIs. The VM label setter is additionally gated to macOS 27.Validation
DEVELOPER_DIR=/Applications/Xcode-beta.app/Contents/Developer /usr/bin/xcrun swift buildDEVELOPER_DIR=/Applications/Xcode-beta.app/Contents/Developer /usr/bin/xcrun swift test --filter 'VMTests|NetworkVmnetTests'/usr/bin/xcrun swift build/usr/bin/xcrun swift test --filter VMTestsI have not run a full VM smoke test with
--net-vmnet-exposeyet, so the remaining validation gap is runtime behavior against macOS vmnet.