on 26-May-2015 04:00
I've used VMware workstation on Windows and Fusion on OS X for quite some time and I'm a big fan of both platforms. That said, the lack of a network settings editor built in to Fusion (I understand it's now available in the Pro version of Fusion) can be more than a little frustrating, particularly if you want a custom experience.
Why custom? Well, you just might want to do more with your BIG-IP VE Lab license than just connect to it and test iRules, and that might require more than just a nic or two. Custom network capabilities enable you to mock up complete environments rapidly.
If you are importing an existing VE instance (as I did) and you have not yet set up your custom networking, you will see that the nic is unrecognized if it was previously configured for additional networking as show in the figure below.
If you are installing a new VE instance, set up your networking first. This is accomplished by editing the networking file located in your /Library tree. You can edit this file by typing this command:
sudo vi /Library/Preferences/Vmware\ Fusion/networking
Once you are in edit mode, you can insert the text below between the VNET_1 and VNET_8 sections.
answer VNET_2_HOSTONLY_NETMASK 255.255.255.0 answer VNET_2_HOSTONLY_SUBNET 192.168.102.0 answer VNET_2_VIRTUAL_ADAPTER yes answer VNET_2_VIRTUAL_ADAPTER_ADDR 192.168.102.1 answer VNET_3_HOSTONLY_NETMASK 255.255.255.0 answer VNET_3_HOSTONLY_SUBNET 192.168.103.0 answer VNET_3_VIRTUAL_ADAPTER yes answer VNET_3_VIRTUAL_ADAPTER_ADDR 192.168.103.1 answer VNET_4_HOSTONLY_NETMASK 255.255.255.0 answer VNET_4_HOSTONLY_SUBNET 192.168.104.0 answer VNET_4_VIRTUAL_ADAPTER yes answer VNET_4_VIRTUAL_ADAPTER_ADDR 192.168.104.1 answer VNET_5_HOSTONLY_NETMASK 255.255.255.0 answer VNET_5_HOSTONLY_SUBNET 192.168.105.0 answer VNET_5_VIRTUAL_ADAPTER yes answer VNET_5_VIRTUAL_ADAPTER_ADDR 192.168.105.1 answer VNET_6_HOSTONLY_NETMASK 255.255.255.0 answer VNET_6_HOSTONLY_SUBNET 192.168.106.0 answer VNET_6_VIRTUAL_ADAPTER yes answer VNET_6_VIRTUAL_ADAPTER_ADDR 192.168.106.1 answer VNET_7_HOSTONLY_NETMASK 255.255.255.0 answer VNET_7_HOSTONLY_SUBNET 192.168.107.0 answer VNET_7_VIRTUAL_ADAPTER yes answer VNET_7_VIRTUAL_ADAPTER_ADDR 192.168.107.1
You don’t have to add as many vnics as I did, and you can adjust the IP space and enable DHCP (check the VNET_1 config for details) in the networks as well if desired. Save and restart Fusion and you should be good to go. Looking back at my VE instance NIC2 config, it properly placed my nic into vmnet2 (same as it was pre-import,) but I now have the flexibility to change to any of these networks.
Thanks for this, but how do I determine the default gateways for each network?
Thanks for the pointers here and that's a great article. However, just wanted to give a quick update here since there were a couple of changes since MacOS BigSur and VMware Fusion updates.
The edit on /Library/Preferences/Vmware\ Fusion/networking remains the same and thanks for that.
However, on top of that I had to manually create "/Library/Preferences/VMware\ Fusion/vmnetX" folder (where X is the vmnet number you picked) for each vmnet added to "networking" config above. I also copied the "dhcpd.conf" from "vmnet1" as template and edited it and changed the addresses accordingly.
The "vmnet" interfaces no longer magically appear like in your example above. I had to type this command:
$ sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop $ sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start
And then I was able to select the vmnetX interfaces I created.
Are there any suggestions on how to get this working in Fusion when running on macOS Big Sur. You can no longer set up DHCP on additional vmnet's.