When working on a project where we need to run software that typically runs on another operating system, virtualization can be a very useful tool. On macOS, VMware Fusion is an excellent choice for this; it has many time-saving features, and its compatibility is top-notch—especially if you need to run Windows or macOS itself in a VM.
By default, Fusion provides several basic virtual networking options that can satisfy most requirements. If you need a little more, customization is fairly easy, though undocumented—and information on how to customize is scattered. The Pro version has a network editor, but if you don’t need the rest of what that version offers, or you’re just curious how VMware Fusion networking works, this article can help you.
Out of the Box
A brand-new VMware Fusion installation (8.5.4 at the time of this writing) offers a handful of networking options:
- NAT, a.k.a. “Internet Sharing: Share with my Mac,” hides your virtual machine behind your Mac’s network address, allowing it to access anything your Mac can, most notably the Internet if you’re connected. However, it doesn’t allow other computers that can access your Mac to access the virtual machine. Most virtual machines are connected this way—it’s the default. This network is available on your Mac as the
- Bridged makes your virtual machine appear as if it were another computer on one of your Mac’s network interfaces. Your virtual machine can talk to everyone else on the network, and everyone else on the network can talk to your virtual machine.
- Host-Only, a.k.a. “Custom: Private to my Mac,” is the one out-of-the-box custom network you get. You can use it to communicate between your Mac and your virtual machines, or between virtual machines if they’re all connected to it. This network is available on your Mac as the
In my case, the latter option was what I went for first—but it didn’t turn out to be quite what I’d hoped for. The virtual machines I was using were already configured to talk to each other using their own IP address scheme and could see each other just fine over
vmnet1—virtual networks don’t care what protocols you use over them. However, my Mac could not talk to those machines, as it was using an IP address (issued by the DHCP server Fusion runs by default on that network) that was not in the same subnet.
I found I could make it work temporarily with a quick
sudo ifconfig vmnet1 10.0.0.128, but the next time Fusion restarted, the Mac’s configuration had reverted. That didn’t stop the DHCP server, either, which could have caused problems if a virtual machine tried to use it!
Changing It Up
The key to customizing Fusion’s networking is the directory
/Library/Preferences/VMware Fusion. In there, you’ll find a file called
networking, which is the master configuration file for Fusion networking. You can edit this file with
sudo when Fusion is shut down (which also tears down any virtual networks); changes will be picked up and applied the next time you start Fusion.
networking file looks similar to this:
VERSION=1,0 answer VNET_1_DHCP yes answer VNET_1_DHCP_CFG_HASH F5FEE30FD06F6A58C7B1B1C2497C54BE04676E98 answer VNET_1_HOSTONLY_NETMASK 255.255.255.0 answer VNET_1_HOSTONLY_SUBNET 192.168.32.0 answer VNET_1_VIRTUAL_ADAPTER yes answer VNET_8_DHCP yes answer VNET_8_DHCP_CFG_HASH 0AEB0A5DAC06201088354E25F52B115FF3F6609F answer VNET_8_HOSTONLY_NETMASK 255.255.255.0 answer VNET_8_HOSTONLY_SUBNET 172.16.110.0 answer VNET_8_NAT yes answer VNET_8_VIRTUAL_ADAPTER yes
In this file, the
VNET_1 answers correspond to
vmnet1, the included host-only network, and
VNET_8 is for
vmnet8, the NAT network that all virtual machines that need Internet access use.
I recommend you don’t change either one of these networks’ configurations. Instead, you can add your own networks, supplying new
answer directives by adding lines for
VNET_3, and so on. You can make additional networks past
VNET_8, too—just skip to
VNET_10, and so on. (I don’t know how far these go, but I haven’t run out yet!)
In my example, I needed a new host-only network where I could attach my virtual machines. This network would not have DHCP, and I would want my Mac to have a fixed address on that network. I added these lines to
networking, which—once the virtual machines were configured appropriately—allowed my Mac to talk to the other virtual machines (on 10.0.0.1 and 10.0.0.253, in the 10/16 subnet):
answer VNET_2_HOSTONLY_NETMASK 255.255.0.0 answer VNET_2_HOSTONLY_SUBNET 10.0.0.0 answer VNET_2_VIRTUAL_ADAPTER yes answer VNET_2_VIRTUAL_ADAPTER_ADDR 10.0.0.128
Writing Your Own Configuration
Here’s what every setting in the configurations above means. I haven’t needed any more than these settings to establish the configurations I need.
- Set to
yesif you want Fusion to run a DHCP server on this interface. For most custom configurations, you won’t want this, but if you’re just trying to isolate virtual machines on their own network without any pre-existing configuration and would find DHCP handy, by all means turn it on!
- Used by Fusion to track the DHCP configuration files it writes out. I am not entirely sure how this works, but I haven’t had to change it.
- The subnet mask for the interface.
- The subnet address for the interface. If you’re using DHCP, this and the mask will be used to figure out how to configure it.
- Set to
yesto provide NAT for virtual machines on this network so they can access your Mac’s real network interfaces.
- Set to
yesto put your Mac on the virtual network. If you want virtual machines to communicate with each other but not your Mac, then don’t use this.
- Set to the fixed address you want your Mac to use on a virtual network. If you don’t use this, your Mac will use DHCP if available (Fusion will give it a fixed lease), or the first available address in the subnetwork.
If these aren’t enough for you, you can also peek into the
vmnetn directories that are created and edit some of the network configuration files, like
nat.conf. The former may be particularly useful if you want Fusion to give DHCP configurations containing, say, custom name servers. Heed any warnings in the files carefully, though! Fusion’s autoconfiguration can create a confusing situation if you don’t.
Once you’ve got the network configuration the way you think you want it, start Fusion again. If your networks have
VNET_n_VIRTUAL_ADAPTER on, you’ll be able to see them when you run
Connecting your virtual machines to your new virtual networks is done in the settings for each virtual machine. You can reconnect an existing virtual network adapter to a different network at any time (much like you can unplug a network cable from a network port and plug it into a new one on a real computer).
If you want to add additional virtual network adapters to your virtual machine, you’ll have to shut it down. You can then use the “Add Device…” button to add as many as you need—or at least eight, which is where I stopped trying.
Once your virtual machines are running, you should be able to
ping them both ways, assuming no firewalls are in play. And if that works, you should be good to go.
This VNET_n_DHCP_CFG_HASH value is a SHA1 checksum of the “DO NOT MODIFY” section of the dhcpd.conf file, including the ‘beginning of’ and ‘end of’ comments. VMware Fusion generates this whenever it regenerated the dhcpd.conf file.
The inability to setting a static ip addr to a Fusion custom network has been a thorn in my side for a long time.
This was a perfect solution for me. Now I don’t have to jump thru hoops with pre-defined addressing in my dev VMs.
Thank you for this post !!!
Great write-up, thanks. My question is, am I able to tag each new VMnet to a different VLAN? For example, I’ll have four VMnets in my example, each will be a unique L3 subnet, but, I need to map each to a different VLAN. Can this be done?
I don’t know anything about setting up VLAN tags with this file, unfortunately. Is that something that Fusion Pro can do? You could get a trial and see.
Comments are closed.