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!
On my system, I only had a few bridged interfaces, but there were still a lot of files there:
root@my-server:/proc/vmnet# ls
bridge0 hub0.1 hub0.5 hub1.1 hub1.5 userif22 userif50 userif66
bridge1 hub0.2 hub0.6 hub1.2 hub2.0 userif23 userif51 userif73
bridge2 hub0.3 hub0.7 hub1.3 hub3.0 userif24 userif64 userif74
hub0.0 hub0.4 hub1.0 hub1.4 netif0 userif4 userif65 userif75
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:
root@my-server:/proc/vmnet# cat bridge0
connected hub0.0 mac 00:50:56:00:00:00 ladrf 00:00:00:00:00:00:00:00 flags IFF_RUNNING,IFF_UP,IFF_PROMISC dev eth0
root@my-server:/proc/vmnet# cat bridge1
connected hub2.0 mac 00:50:56:00:00:00 ladrf 00:00:00:00:00:00:00:00 flags IFF_RUNNING,IFF_UP,IFF_PROMISC dev eth1
root@my-server:/proc/vmnet# cat bridge2
connected hub3.0 mac 00:50:56:00:00:00 ladrf 00:00:00:00:00:00:00:00 flags IFF_RUNNING,IFF_UP,IFF_PROMISC dev vmnet1
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. If you’ve got any better ways to get this information, please post them in the comments or email tips@itsnotthenetwork.com.
As part of our 