The other day I was trying to help troubleshoot a networking problem with our Virtual Appliance on a VMware Linux Host. I could pretty easily surmise that the problem was somewhere in the configuration, but I was unable to tell what exactly the host’s networking configuration was because you must run vmware-config.pl to configure the network on a Linux VMware host (Windows has the very handy “Manage Virtual Networks” tool that you can use, but alas, no such analog exists on a Linux host, to the best of my knowledge). The problem with running vmware-config.pl is that it requires all virtual machines to be turned off before it will even show you any information, which is a total pain when I just want to see what is bridged to what. So I went searching for a way to extract the information I wanted form the system, and eventually I found it (I was unable to find it on a google search or by searching the VMTN Forums or VMware Knowledge Base, which is pretty rare, so I ended up digging through my own files to find it). Eventually I discovered that the information I was after was stored in /proc/vmnet, which has an entry for each vmnet that is configured on the system. By simply looking in the files, I was able to tell what was going on, hooray!

A little exploring and I was able to surmise that hubX mapped to what we commonly know as vmnetX, with X usually being 0,1, or 8 for a default VMware configuration (in Windows land these are usually called “VMware Network Adapter VMnetX”). I think the hubX.Y files actually show which interfaces of which running machines are connected to that hub, kind of like link lights on a real hub, but I didn’t spend enough time to really be sure. In any case, I was able to determine that since I only have bridges configured on this system, the files bridge0, bridge1, and bridge2 were the ones I was after:

It is pretty plain to see that bridge0 connects hub0 (aka vmnet0) to eth0, bridge1 connects hub2 (aka vmnet2) to eth1, and bridge2 connects hub3 (aka vmnet3) to vmnet1 (I’ll explain this funky mapping another time).

Hopefully someday VMware will implement a handy tool like the Windows “Manage Virtual Networks” tool on Linux hosts, but until then, this will be good enough for me to at least tell what is going on on an unknown system.

This article is copyright OPNET Technologies, Inc., and is reprinted from the original at www.itsnotthenetwork.com with permission.