I see 'virbr0' in the output of ifconfig. Did you happen to install virtualization packages? That won't work on a VM guest.

I'd definately make sure the vmware tools is proper...

HOPEFULLY THIS IS JUST A MATTER OF REINSTALLING VMware Tools! I have had to re-install VMware tools numerous times in the past due to upgrades etc. If that is the case - hopefully you will not need the rest of what I wrote below!!

On vm systems, and starting with rhel 6 and above, make sure the MAC address in
/etc/udev/rules.d/70-persistent-net.rules file matches what is on the interface.

**Make note of the MAC address in /etc/udev/rules.d/70-persistent-net.rules for the specific interface

[root@yoursystem ~]# cd /etc/sysconfig/network-scripts
[root@yoursystem ~]# grep -i eth /etc/udev/rules.d/70-persistent-net.rules

Next, Determine which network interface should be up (do you have ifcfg-eth0 or ifcfg-em0?)

[root@yoursystem network-scripts] grep ONBOOT ifcfg* | grep -v ^\# | grep yes

Whichever interface the system claims is up - make a note of the HWADDR

[root@yoursystem network-scripts] grep HWADDR ifcfg* | grep -v ^\#

now go to the "edit properties" function in VMWare and click on the specific network interface (on your virtual system)
Questions for you: Does the MAC address AND the device "ifcfg-ethX" match what is in:
1) /etc/sysconfig/network-scripts/ifcfg-ethX (the one you identified a few lines up)
2) /etc/udev/rules.d/70-persistent-net.rules
3) The VMWare virtual NIC as shown in the "edit settings" hardware tab

**If /etc/udev/rules.d/70-persistent-net.rules shows your network interface should be (for example) ifcfg-eth1, then /etc/sysconfig/network-scripts/ifcfg-eth1 should 1) exist and 2) have the matching MAC address. This may sound like it would not apply, but I've seen it occur a number of times to be relevent enough to check if other simpler checks prove false.

If VMWare tools and the MACs and the devices all agree - this typically takes care of the consternation I have found with virtual systems.

• I've seen systems that have an "ifcfg-eth2" with the MAC address in the /etc/udev/rules.d/70-persistent-net.rules not match the device in /etc/sysconfig/network-s
  cripts/ifcfg-ethX
  -- example, the hardware address and interface in /etc/udev/rules.d/70-persistent-net.rules may show as 'ifcfg-eth1' when in /etc/sysconfig/network-scripts/ifcfg-eth0 EXISTS, but here is no /etc/sysconfig/network-scripts/ifcfg-eth1
• if that is the case (no ifcfg-eth1 file exists, but the file 70-persistent-net.rules file shows eth1 for that MAC), is copy the ifcfg-eth0 to ifcfg-eth1 and make the MAC address in ifcfg-eth1 match wht is in 70-persistent-net.rules match. Verify selinux contexts, and (if that is the case) disable completely ifcfg-eth0.

anyway, that scneario has occured more than a few times on some virtual systems I have had.

HOPEFULLY IT IS JUST A MATTER OF REINSTALLING VMWare tools!!!

Hi Kevin,

I've had something like this occur -

Check to see the output of lspci:

[root@yoursystem ~]# lspci | grep -i eth

Probably no output will generate.

Some immediate possible options:
1) Just for yuks, reinstall vmwaretools, however this time do it manually (attach the iso from the graphical vmware interface), hopefuly it is in/on one of your VMware data stores, otherwise burn it to a cdrom and attach the cdrom. Else, attach the iso using the graphical disk icon. Then, do a:

mkdir -p /mnt/notmounted /cdrom/notmounted;chmod 755 /cdrom

Then mount it and run the manual installation of vmware, (the automated vmware install can betray you silently):

[root@yoursystem ~]# mount /dev/cdrom /cdrom
[root@yoursystem ~]# ls /cdrom/ ## should show VMwaretools with some gz file
[root@yoursystem ~]# df -PhT # look for a place to put the small gz file
[root@yoursystem ~]# mkdir /tmp/vmwaretoolsdeleteafterwards/
[root@yoursystem ~]# rsync -au --progress /cdrom/ /tmp/vmwaretoolsdeleteafterwards/
[root@yoursystem ~]# cd /tmp/vmwaretoolsdeleteafterwards/
[root@yoursystem ~]# gunzip NAME-OF-GZIPP'D-VMWARE-TOOLS-FILE-GOES-HERE.gz
[root@yoursystem ~]# tar -xvf NAME-OF-TAR-VMWARE-TOOLS-FILE-GOES-HERE.tar
[root@yoursystem ~]# cd vmwaretools-distrib # I think
[root@yoursystem ~]# ./install.pl # I think
[root@yoursystem ~]# echo "TAKE ALL DEFAULTS"
[root@yoursystem ~]# echo "continue taking all defaults until it is complete"
[root@yoursystem ~]# echo "the initrd will be made at the end and the script should report as completed"
[root@yoursystem ~]# 
[root@yoursystem ~]# lspci | grep -i eth
[root@yoursystem ~]# echo "hopefully you get some output on your devices"
[root@yoursystem ~]# echo "reboot the box and if needed, upgrade the 'virtual hardware' of the system while the system is down"
[root@yoursystem ~]# echo "after reboot, go to the /etc/sysconfig/network-scripts and see if ifcfg-ethX files exist, else remove existing interfaces and install new virtual NIC"

Hope this helps

Kevin,

Do you happen to have a snapshot for the system under VMware for the system prior to the changes that were made? (or did the interface ever work)?

That bit you describe above happened to me a while back as well and I believe I had to install the following: kernel-headers, kernel-devel, glibc and gcc..

• Make a local yum repo with your RHEL 7 disk - scroll down to paragraph 5.5.6.. Attach the DVD or RHEL 7 iso to the system and create a local yum repo.
• You might need the following three rpms. You will have to find them on your RHEL 7 DVD.

mkdir /cdrom
chmod 755 /cdrom
mount /dev/cdrom /cdrom
rsync -au --progress /cdrom/  /path/to/a/directory/with/enough/space/local/yum/
cd /to/the/path/to/your/local/yumrepo/
echo "cd to the directory with the below packages"
echo "look around in the directories in the yum repo location for these files."
rpm -ivh deltarpm-VERSION python-deltarpm-VERSION createrepo-VERSION
createrepo -v /path/to/your/local/yumrepo

Properly edit your /etc/yum.repos.d/local.repo file

According to this VMware video, you must have glibc and gcc along with kernel-headers and kernel-devel. So a yum repo will help get these rpms and their dependencies.

After you create the local yum repo and install the rpms, try the install of vmwaretools (manually) again.

Good luck,

Rem

Hope this helps

Kevin,
I had the same problem with the kernel headers, try

yum install kernel-headers-`uname -r` kernel-devel-`uname -r` 

then the header path is something like this : "/lib/modules/3.10.0-123.el7.x86_64/build/include"

It would be good if we could fork this topic on the forum as I ran into the same problem with the ifconfig command however it was easily solved with net-tools.