ifup: vmnics device eth0 does not seem to be present, delaying initializing

[Ronaldp]

Hello

After upgrading my RHES 4 to the latest kernel release I noticed in the startup of my vm that he was showing an error on my vmware-tools.

The system said I had to reconfigure my vmware tools. After doing that i rebooted the server and now he doesn't automatically start my eth0. When i go to network setting and i start the mic my network recovers.

What can that be?

Regards Ronald P.

[admin]

Check that /etc/sysconfig/network-scripts/ifcfg-eth0[/b] contains the line ONBOOT=yes[/b]

[boydd]

Verify the above - but I have also seen that after any kernel updates you may have to reinstall/reconfig the vmtools.

DB

[jbsengineer]

I'm seeing this on a fresh install of RHEL 4 as well. Tryied to re-configure/re-install tools and same thing. The NIC functions correctly but it just errors on bootup. Anyone else seeing this in a RHEL 4 box?

[acr]

Any time we ever get a problem with RHES we always seem to uninstall reinstall the tools..!!

[johnshen]

got exactly the same thing with mandriva2007 guest. actually it works on the first boot after installation of guest, but it got lost after a reboot.

dmesg | grep eth0 shows it is present as pcnet32

pcnet32 kernel module is also loaded fine.

weird problem.

[johnshen]

I figured out my problem. It seems that after vmware-tools installation eth0 became eth1

I had to use static mac address in the configuration and add HWADDR="macaddress" to force it to be eth0 again. Now it works. It took me a while to realize that this is what is going on.

[adt22]

I've also got mandriva2007 and found that after a reboot the eth switched to eth1 from eth0. I hadn't installed vmware-tools -- the strange thing that I did was to "ghetto clone" a vm by copying the vmdk files and create a new custom vm using those disks.

The source vm worked fine. But after the first reboot the new vm wouldn't get on the network, giving "pcnet32 device eth0 does not seem to be present" when I ran "ifup eth0".

Thanks johnshen for posting the tip on HWADDR, it fixed it for me -- I never would have figured that out. I guess this is a mandriva peculiarity?

-Amir

[kjbrady]

You might also try running 'depmod -a'. It appears the vmware tools install doesn't rebuild the database modprobe, etc. use to locate the modules. This command will do that, this combined with removing the HWADDR line from ifcfg-eth0 fixed everything for me.

[bbh]

I had the same problem on a Debian Etch.

After installation of vmware-tools, i added the alias line (alias vmxnet eth0)

to /etc/modprobe.d/alias, and everything worked again

[Texiwill]

Hello,

Linux kernels > 2.6.18 do not have vmware-tools that work. I am working on some patches but even the any-any patch will not compile the vmware-tools properly.

When you installed vmware-tools and the builds broke, the file /etc/modprobe.conf was still updated. Edit the file....

1) change the 'alias eth0 vmnics' line to read 'alias eth0 pcnet32'

2) Delete all lines after and including the 'Added by VMware' comment.

This will allow your eth0 device to work properly again.

I was able to properly patch the vmmemctl driver with no issues however. My attempts to patch the other drivers including vmxnet did not work yet. Still working on it as there was a serious change to the CHECKSUM code between 2.6.18 and later versions of the kernel.

To put this patch in do the following:

as root

cd /usr/lib/vmware-tools/modules/source

cp vmmemctl.tar vmmemctl.tar.orig

tar -xf vmmemctl.tar

cd vmmemctl-only

patch -p1 < /tmp/vmmemctl-only.patch

cd ..

tar -cf vmmemctl.tar vmmemctl-only

rm -rf vmmemctl-only

cd /tmp

vmware-config-tools.pl

When the builds fail for vmhgfs, vmxnet answer 'NO' to the question. That way they will not take effect.

Also, you will once more need to edit /etc/modprobe.conf per the beginning of this post. Yet, now the memory module is compiled and it will interact with ESX nicely. I am working on the vmxnet module next. My first attempt did not work very well and I am not sure why yet.

Best regards,

Edward

diff -c -b vmmemctl-only-orig/os.c vmmemctl-only/os.c

\*** vmmemctl-only-orig/os.c 2007-03-30 13:54:30.000000000 -0400

\--- vmmemctl-only/os.c 2007-06-13 11:35:11.000000000 -0400

***************

\*** 23,29 ****

\--- 23,31 -

---

#include "driver-config.h"

+ #if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,18)

#include <linux/config.h>

+ #endif

#ifdef MODULE

#include <linux/module.h>

[nikv]

Where can i get vmmemctl-only.patch ???

[SashaGrybyuk]

We just had simular issue after upgrading vmware tools on CentOS.

Fixed it by upgrading virtual Hardware and reruning vmware tools config tool.

[virtualsmoot]

Seen this exact same issue on RHEL VMs after Linux kernel updates.   I think the VMware driver fails. Reinstalling VMware tools (manual or unattended) then reboot and network was back fine.

[roconnor]

Hi

Take a look in /etc/udev/rules.d for the networking file on the vm and check the MAC addresses there.

You can remove the persistent udev rules file and let it regenerate:

service network stop

rm /etc/udev/rules.d/70-persistent-net.rules

Then remove the HWADDRESS from the ifcfg-ethX file all together

start_udev

service network start

take a look at

Reconfiguring Network Interfaces in CentOS/RHEL Systems Cloned with vCenter &amp;laquo; AlexCline.ne...

regards

Russ

[jackril]

Step1: Make sure that the MACADDR of the affected NIC in the ifcfg-eth'x' file is same as that of the MAC address in the advanced configuration of the NIC (From the VM settings)

Step2: Then remove the file /etc/udev/rules.d/70-persistent-net.rules and reboot your system.

# rm /etc/udev/rules.d/70-persistent-net.rules

VMware workstation : 12.1.1 build-3770994

RHEL: 6.5

Worked like charm!!!!!