GNS3 "No VMnet interface available": how to fix it

You start a VMware VM in a GNS3 topology and get No VMnet interface available between vmnet2 and vmnet19. Go to preferences VMware / Network / Configure to add more interfaces. GNS3 needs a free host-only VMnet for each network adapter of that VM, and it found none in the range it manages. On macOS and Linux the second number is higher (often vmnet100 or vmnet255), but the cause is the same.

Why it happens

GNS3 doesn't plug a VMware VM into your topology through VMware's own networks. It switches each of the VM's adapters to a "custom" network, gives every adapter a VMnet of its own, and bridges that VMnet into the lab with uBridge. You can see this in the VMware code of gns3-server. Four rules decide whether a VMnet is usable:

• VMnet0, VMnet1 and VMnet8 never count. They are VMware's bridged, host-only and NAT networks. The GNS3 documentation says GNS3 won't use them. A fresh VMware install has only these three, so you start with zero.
• One VMnet per adapter. A firewall VM with 5 adapters takes 5 VMnets. Two of them running at once take 10. A GNS3 developer confirmed this in gns3-gui issue #2081.
• Only the managed range. GNS3 only takes VMnets between the start and end you set in its preferences. The default is vmnet2 to vmnet19 on Windows and vmnet2 to vmnet100 on macOS and Linux. Windows stops at 19 because VMware Workstation on a Windows host has VMnet0 to VMnet19.
• The host adapter must exist. On Windows and Linux, GNS3 finds VMnets by looking for the host network adapter VMware creates for them. A VMnet without a host virtual adapter is invisible to it.

Fix it

1. Let GNS3 create the VMnets

This is the simplest fix and works on Windows, macOS and Linux.

1. Close any running VMware nodes.
2. Open Edit > Preferences > VMware and go to the Advanced local settings tab.
3. Under Managed VMnet interfaces (VMnet8 excluded), set the range. On Windows, vmnet2 to vmnet19 gives you 17 usable VMnets (2 to 7 and 9 to 19).
4. Click Configure and accept the administrator prompt.
5. Wait. On Windows it calls VMware's vnetlib once per VMnet, which can take several minutes.
6. Click OK, close GNS3 and open it again.

On Windows, the Configure button runs a tool that adds a VMware host adapter for each number in the range. On macOS and Linux, the same tool (gns3vmnet) writes the VMnets into VMware's networking file with a 172.16.x.0/24 subnet each, then restarts VMware's networking.

If you run GNS3 2.2.41 on Windows and Configure fails with name 'sys' is not defined, that is a known bug fixed in 2.2.42. Update GNS3.

On Linux you can do the same from a terminal. -l lists the VMnets that exist, -r adds a range:

sudo gns3vmnet -l
sudo gns3vmnet -r 2 19

2. Or create them in VMware Workstation

If you prefer to stay in VMware, open Edit > Virtual Network Editor (click Change Settings if it asks for administrator rights). Broadcom documents the editor in this article. For each VMnet you need:

1. Click Add Network and pick a number inside the managed range, such as VMnet2.
2. Choose Host-only.
3. Keep Connect a host virtual adapter to this network ticked.
4. Clear Use local DHCP service to distribute IP address to VMs. The GNS3 docs ask for DHCP to be off on the VMnets it uses.
5. Click Apply, then restart GNS3.

3. Use fewer adapters

If you only need two links, don't give the template eight adapters. Right-click the VMware VM template in the devices panel, choose Configure template, go to the Network tab and lower Adapters. Every adapter costs a VMnet, whether or not it has a link.

4. Leave the VM's network settings to GNS3

In the same template, keep Allow GNS3 to override non custom VMware adapter ticked, as the GNS3 docs recommend. Without it, an adapter set to NAT, bridged or host-only in VMware is left alone, and linking it fails with an error like Attachment 'nat' is already configured on network adapter 0. Please remove it or allow VMware VM 'Win10' to use any adapter. Once the VM is in a topology, don't change its network adapters in VMware.

How to check it worked

List the VMnets your host has. On Windows, in PowerShell:

Get-NetAdapter -Name "*VMnet*" | Sort-Object Name | Format-Table Name, Status

You should see one VMware Network Adapter VMnetN line for each VMnet in your range. On Linux, ip -br link | grep vmnet shows the same. On macOS with VMware Fusion:

grep VIRTUAL_ADAPTER "/Library/Preferences/VMware Fusion/networking"

Then start the VMware node. It should boot without the error, and a link to it should pass traffic.

If it still fails

• You run out at runtime. The count covers every VMware node that is running. Add up the adapters of all of them, or widen the range on macOS and Linux.
• The range doesn't match. The numbers in the error are the range the server uses. If you created VMnet20 to VMnet30 by hand, set the managed range to match. The server reads it from vmnet_start_range and vmnet_end_range in the [VMware] section of gns3_server.conf (gns3_server.ini on Windows).
• macOS 11 or later with old GNS3. GNS3 2.2.34 and older couldn't see existing VMnets on Big Sur and later, because VMware Fusion uses bridge interfaces there. It was fixed in 2.2.35 (issue #3381). Update GNS3.
• The VMnets are in a bad state. The Reset button next to Configure deletes the VMnets GNS3 manages so you can create them again. It deletes every VMnet except VMnet1 and VMnet8, so don't use it if you rely on other custom VMnets for VMs outside GNS3.

For more GNS3 fixes, see the GNS3 troubleshooting guide. If the GNS3 VM itself won't start because of VT-x, read VT-x not available on Windows.

A lighter way to build the lab

If the VMware VMs in your lab are plain Linux hosts or simple services, you may not need VMware networking at all. Isothrum's editor is free, runs in your browser with no account, and exports a network lab of containers as Docker Compose, or a lab of VMs as Vagrant. A lab of containers needs no VMnets and no GNS3 VM. For VMs that must stay in VMware, the fix above is the way.