Enhance bridge networking with helper-based bridging support#1622
Open
curdbecker wants to merge 7 commits into
Open
Enhance bridge networking with helper-based bridging support#1622curdbecker wants to merge 7 commits into
curdbecker wants to merge 7 commits into
Conversation
- Attachment.ipv4Address and .ipv4Gateway made optional; bridge attachments carry no pre-allocated IP (assigned via DHCP at runtime) - Update all call sites and tests for optional IP fields Co-authored-by: Curd Becker <me@curd-becker.de>
The setter for adding an XPCDictionary to an XPCMessage is present, but the getter to retrieve it again is missing. This might be connected to the fact that xpc_endpoint_t is a type alias to xpc_object_t, so they appear to use an identical setter implementation (unless there is some implicit argument overloading that I am not aware of), but they apparently they cannot use the same getter method, since there is a dedicated `xpc_dictionary_get_dictionary` method to retrieve the dictionary again.
Right now, the configuration for a network is only saved in the `NetworksService` after the network has been successfully started. However, that constitutes a dependency issue when the vmnet helper implementation depends on options in order to be able to create and start the network in the first place. This commit fixes this issue by passing the options (excluding the variant) explicitly along as a serialized json dictionary. This is not that elegant, but works well for now. To me it looks also that this area is still undergoing quite some refactoring, so this might be a workaround until a more elegant permanent solution is implace.
For each bridge attachment (ipv4Address == nil) at interface index n, append ip=:::::eth<n>:dhcp to the kernel cmdline before booting the VM. The kernel's built-in DHCP client (CONFIG_IP_PNP_DHCP=y) acquires the lease before userspace starts, so no DHCP binary is needed in the rootfs. We also pass the hostname to the DHCP server. VZVirtualMachineManager creation is moved after attachment allocation and interface creation, so interface indices are known when the cmdline is finalized. Co-authored-by: Curd Becker <me@curd-becker.de>
This was previously just a private enum inside the NetworkVmnetHelper entrypoint, but it makes sense to make this actually globally accessible ... at least for now. I imagine this is also going to be likely the focus of the ongoing refactoring.
…rategy
Implements the vmnet plugin side of bridge networking: a new
BridgedVmnetNetwork actor that uses placeholder subnets (no IP pool) and
a .bridged/.bridgedViaHelper NetworkVariant for the plugin helper.
The BridgeInterfaceStrategy communicates XPC additional data payload
forwarded by the BridgedVmnetNetwork to the concrete network interface.
BridgeInterfaceStrategy maps:
- .bridged network attachments to a BridgedNetworkInterface
for the given host interface.
- .bridgedViaHelper network attachments to a FileHandleNetworkInterface
for the FileHandle endpoint where the plugin helper will provide
bridging services to the runtime.
Co-authored-by: Curd Becker <me@curd-becker.de>
The BridgeNetworkService is heavily inspired by nirs/vmnet-helper and draws on the same concept. This allow bridging to a real host network interface without having a binary signed with the com.apple.vm.networking entitlement, e.g. during container development. Therefore, the service allocates a standalone vmnet interface and a dedicate UNIX datagram socket pair. One end of the pair remains local to the service as the network attachment of the runtime, the other end is sent to the runtime where it is assigned in the underlying VM configuration as `VZFileHandleNetworkDeviceAttachment`. This setup allows the service to perform manual bridging between the vmnnet network interface attached to the host interface and the runtime using event handlers on both sides. While this is obviously certainly less performant and generally inferior to having the same capabilities integrated directly in the Virtualization Framework, it provides a very similar setting and is actually possible without root privileges or any special entitlements.
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
3 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.
Type of Change
Motivation and Context
Based on @torarnv's existing pull request, this pull request introduces support via a
BridgeNetworkServicein the vmnet plugin helper to enable socket-based bridge forwarding. TheBridgeNetworkServiceis heavily inspired by nirs/vmnet-helper and draws on the same concept - although simplified only towards bridge networking with a vmnet interface and lacking basically all performance optimization so far.This allow bridging to a real host network interface without having the binary signed with the
com.apple.vm.networkingentitlement, e.g. during container development.In addition, this pull request rebases the changes of the existing pull request on the refactoring done in the current main branch which seems to working towards a more general network plugin interface and also introduces several, likely temporary enhancements to bridge the current gap of getting the network configuration options actually to the network helper during creation.
Specifically, the bridged networking understands two additional variants:
.bridgednetwork attachments to a BridgedNetworkInterface for the given host interface from the original PR..bridgedViaHelpernetwork attachments to a FileHandleNetworkInterface for the FileHandle endpoint where the plugin helper will provide bridging services to the runtime.Simple example:
Requires apple/containerization#759 (also based on @torarnv's work)
Extends #1463
Fixes #489
Testing