Portal Home > Knowledgebase > VMware Knowledge Base > Verifying the networking within a Linux based guest operating system

Verifying the networking within a Linux based guest operating system


  • Virtual machine does not have network connectivity
  • Virtual machine cannot connect to the network


This article provides steps to verify the network connectivity within a Linux based guest operating system.


If you are having network connectivity issues, verify that the guest operating system is configured properly.
To verify that the guest operating system is configured properly on a Linux virtual machine:

  1. Verify that VMware Tools has been loaded on the guest operating system. In a Linux virtual machine, boot the guest operating system, open a command prompt or run start X and launch your graphical environment. You can then launch the VMware Tools background application using this command:

    vmware-toolboox &

    If the command does not run, VMware Tools has not been installed. It is necessary to have VMware Tools loaded for your NIC to function. For more information, see Installing VMware Tools in a Linux virtual machine using a Compiler (1018414).

  2. Verify that the virtual network adapter is present and enabled by using ifconfig. If nothing appears, this can indicate that the NIC is shut down or not present.

    Note: Network interfaces appear if they are activated, but do not have a link.  Proceed to Step 3 if they appear available.

    # ifconfig

    You see an output similar to:

    eth0  Link encap:Ethernet  HWaddr 00:0C:29:9E:78:5F
          inet addr:  Bcast:  Mask:
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2080 (2.0 KiB)  TX bytes:7037 (6.8 KiB)

    lo    Link encap:Local Loopback  
          inet addr:  Mask:
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1453 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2294308 (2.1 MiB)  TX bytes:2294308 (2.1 MiB)

  3. Verify the link status by using ethtool. If this fails, it indicates an issue with a physical link or improper duplex setting.

    # ethtool eth#

    Where # is the network adapter number as shown in ifconfig.

    For example:

    # ethtool eth0

    You see an output similar to:

    Settings for eth0:

      Supported ports: [ TP MII ]
      Supported link modes:   10baseT/Half 10baseT/Full
                              100baseT/Half 100baseT/Full
      Supports auto-negotiation: Yes
      Advertised link modes:  10baseT/Half 10baseT/Full
                              100baseT/Half 100baseT/Full
      Advertised auto-negotiation: Yes
      Speed: 100Mb/s
      Duplex: Full
      Port: MII
      PHYAD: 32
      Transceiver: internal
      Auto-negotiation: on
      Supports Wake-on: pumbg
      Wake-on: p
      Current message level: 0x00000007 (7)
      Link detected: yes

  4. If a link is detected, ping an outside source to see if you get a response. If this fails, this can indicate a routing issue, or possible DNS problem if a hostname is used. Ping an IP address and hostname to verify both.

    # ping ip address/hostname

    Where ip address/hostname is a known outside IP address or a valid resolvable hostname known to work on other virtual machines or workstations.  

    For example:

    # ping

    PING ( from : 56(84) bytes of data.
    From icmp_seq=1 Destination Host Unreachable
    From icmp_seq=2 Destination Host Unreachable
    From icmp_seq=3 Destination Host Unreachable
    From icmp_seq=4 Destination Host Unreachable
    From icmp_seq=5 Destination Host Unreachable
    From icmp_seq=6 Destination Host Unreachable
    --- ping statistics ---
    8 packets transmitted, 0 received, +6 errors, 100% loss, time 7021ms, pipe 3

    • If you can ping by IP but not by hostname, then check that the DNS name server entires in /etc/resolv.conf file are correct by executing:

      less /etc/resolv.conf
    • If there are no ping replies, then ping the gateway and check network settings by executing:

      less /etc/sysconfig/network

  5. If the ping fails, verify further using the telnet command to test network connectivity:

    # telnet

    For example:

    # telnet 192.168.111 22

    telnet: connect to address Connection refused

  6. If a ping is successful, and you are unable to connect to a specific port, it indicates a blocked port or an active firewall somewhere in your environment. Use the netstat command to verify ports on the source system:

    # netstat -a

    You see an output similar to:

    Active Internet connections (servers and established)
    Proto Recv-Q Send-Q Local Address           Foreign Address         State
    tcp        0      0 localhost:30037         *:*                     LISTEN
    udp        0      0 *:bootpc                *:*                                

    Active UNIX domain sockets (servers and established)
    Proto RefCnt Flags       Type       State         I-Node   Path
    unix  2      [ ACC ]     STREAM     LISTENING     6135     /tmp/.X11-unix/X0unix  2      [ ACC ]     STREAM     LISTENING     5140     /var/run/acpid.socket

  7. If everything appears to be listening and opened, you can use the traceroute command to see where the connection is failing. Generally it is a good idea to use the command to trace your path back to a known good connection in your environment, such as a your vCenter Server, if available.

    # traceroute ip address

    For example:

    # traceroute

    Tracing route to VCENTERSRV []
    over a maximum of 30 hops:

      1   101 ms   100 ms   116 ms  example.yourdomain.com []
      2   138 ms   152 ms   115 ms  core.yourdomain.com []
      3   124 ms   134 ms   138 ms  VCENTERSRV []

    Trace complete.

    If, at anytime, you receive the error message Destination host unreachable, it indicates there is a firewall or device preventing you from establishing a network connection. Note where the failure occurs and troubleshoot from there.

Based on VMware KB 2022022

Also Read