feat: Allow specifying vmnet network UUID to disable DHCP (when in Host mode)

[pallotron]

This commit introduces a new --vmnet-network-uuid command-line option to allow setting the vmnet_network_identifier_key for vmnet.

This property is only applicable to a vmnet_interface in VMNET_HOST_MODE.

If this property is set, the vmnet_interface is added to an isolated network with the specified identifier.

No DHCP service is provided on this network.

This is useful for certain applications where the users need an isolated network and are running their own dhcp to assign IPs in such network.

See issue #139

[nirs]

@pallotron thanks! This Looks like an interesting feature but it is not clear what is the purpose of the new identifier.

[pallotron]

@pallotron thanks! This Looks like an interesting feature but it is not clear what is the purpose of the new identifier.

Thanks for the feedback! You've raised a great point about the purpose of the new identifier. Let me clarify.

The primary goal of this change is to enable running a custom DHCP server on a vmnet network, which is essential for specialized setups like a PXE boot environment.

The Problem

I'm building a virtual lab to test our production PXE boot stack. This involves a "provisioner" VM (running dhcpd, tftp, etc.) and multiple "client" VMs that network-boot from it. For this to work, the client VMs and the provisioner need to be on an isolated network where my custom dhcpd can manage IP allocation.

The issue is that vmnet.framework runs its own DHCP server on VMNET_[HOST|SHARED]_MODE networks by default because it provides IP addresses to the VMs that your are booting.
This is ok for most of the use cases. However this default DHCP server conflicts with the custom one I need to run for the PXE environment, creating a race condition where either macOS or my dhcpd responds to DHCP requests first.

The Solution

While digging into the vmnet.framework headers, I found a solution provided by Apple. According to
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/vmnet.framework/Headers/vmnet.h:

    1 /*!
    2  * @constant vmnet_network_identifier_key
    3  * The identifier (uuid) to uniquely identify the network.
    4  *
    5  * This property is only applicable to a vmnet_interface in
    6  * VMNET_HOST_MODE.
    7  *
    8  * If this property is set, the vmnet_interface is added to
    9  * an isolated network with the specified identifier.
   10  *
   11  * No DHCP service is provided on this network.
   12  */
   13 extern const char * const
   14 vmnet_network_identifier_key API_AVAILABLE(macos(11.0)) API_UNAVAILABLE(ios, watchos, tvos);

By setting the vmnet_network_identifier_key, we can create an isolated VMNET_HOST_MODE network without the conflicting DHCP service. This allows the custom DHCP server in the provisioner VM to function correctly. This feature has been available since macOS 11.0.

This allows me to start multiple client VMs on the same socket_vmnet socket, they can take IP addresses from provisioner VM just fine, the provisioner VM also work as a router and can forward client VMs traffic to the internet.

It's also worth noting that a more explicit API is coming in the future. The same header file mentions:

   1 /*!
   2  * @function vmnet_network_configuration_disable_dhcp
   3  * Disables DHCP server on a network.
   4  */
   5 void
   6 vmnet_network_configuration_disable_dhcp(vmnet_network_configuration_ref config)
   7 API_AVAILABLE(macos(26.0)) API_UNAVAILABLE(ios, watchos, tvos);

This vmnet_network_configuration_disable_dhcp function will be the standard way to achieve this, but it's only available on macOS 26.0 (Tahoe). For now, using vmnet_network_identifier_key + VMNET_HOST_MODE is the correct approach.

I hope this clears things up! Let me know if you have any other questions.
I have seen your other comments and I will address them tomorrow.

[jandubois]

This sounds interesting. I think it would be nice to also provide a template with DHCP, router, and maybe even firewall and proxy, to show users how they can set up isolated networks for testing.

[pallotron]

This sounds interesting. I think it would be nice to also provide a template with DHCP, router, and maybe even firewall and proxy, to show users how they can set up isolated networks for testing.

Are you saying in this PR, I think it would be out of scope for this particular PR. But I agree with you it would be nice.
My project does exactly that. I will see if I can get approval to publish it.

[pallotron]

sorry guys, I had a bicycle incident... I will get back at this and resolve all feedbacks once I can type on my laptop w/o pain :(

[pallotron]

I am back! :)
This should be now satisfy all feedback I recieved.

[pallotron]

@nirs hey can you let me know if the PR looks good now?

[AkihiroSuda]

Please squash the commits
https://lima-vm.io/docs/dev/git/#squashing-commits

[pallotron]

Please squash the commits https://lima-vm.io/docs/dev/git/#squashing-commits

I've squashed the commits as requested. I keep forgetting this specific project rules. Could you now please focus the review on the logical content of the change? I'd appreciate your feedback on the functional aspects which you could have provided when you mentioned about squashing and the stupid space after TIP introduced by stupid vscode markdown plugin.

[AkihiroSuda]

The code looks good