Cloned Red Hat/CentOS/Scientific Linux Virtual Machines and “Device eth0 does not seem to be present” Message
Recently I was preparing some new virtual machines in VMware running Scientific Linux 6. I encountered some difficulty with the virtual network interface after preparing clones of the machines. In particular I was unable to get the virtual NIC on the newly cloned machine to be recognized as a valid interface. Upon further investigation the NIC on the newly cloned machines was being registered as “eth1”. We can check the currently registered “eth” devices here:
[root@sl6 ~]# ls /sys/class/net
eth1 lo sit0
As it turns out there is a device manager for the Linux kernel named “udev” which remembers the settings from the NIC of the virtual machine before it was cloned. I was not familiar with udev because it was not installed in my previous Linux VM install, which were mainly CentOS 5.
Since the hardware address of the network interface changes as part of the clone, the system sees the NIC after the clone as “new” and assigns it to eth1. The simple way to move the interface back to eth0 is to edit the strings beginning with “SUBSYSTEM” in udev’s network persistence file.
Start off by removing the first “SUBSYSTEM” entry that represents the “old” eth0 interface. Then edit the second “SUBSYSTEM” entry, changing the “NAME” parameter from “eth1” to “eth0”. Of course your config may vary from mine. Keep in mind that the “SUBSYSTEM” line may be wrapped in the text below.
Old file:
[root@sl6 ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x15ad:0x07b0 (vmxnet3) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:87:00:21", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x15ad:0x07b0 (vmxnet3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:87:00:25", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
New file:
[root@sl6 ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x15ad:0x07b0 (vmxnet3) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:87:00:25", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Now verify that you have a properly configured network config file, the example below is for Red Hat/CentOS/Scientific Linux:
[root@sl6 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="static"
HWADDR="00:50:56:87:00:25"
IPV6INIT="no"
IPV6_AUTOCONF="no"
NM_CONTROLLED="no"
ONBOOT="yes"
IPADDR="192.168.10.125"
NETMASK="255.255.255.0"
NETWORK="192.168.10.0"
BROADCAST="192.168.10.255"
Now reboot the system and the NIC should now be registered as eth0!
Nice post ! …. this helped a lot !
you can also simply delete the /etc/udev/rules.d/70-persistent-net.rules file and it will be regenerated on reboot.
Thanks for the tip, Alen.
An easier way:
Just delete 70-persistent-net.rules all together and reboot, udev will build a new (correct) 70-persistent-net.rules.
BTW: great site
Thanks, nice article. I migrate some virtual machines from VMware Server 1.x to VMware vSphere Hypervisor 4.1, then Fedora 14 guest os has this problem, but CentOS 5.5 guest os does not has this problem(but still need change HWADDR in ifcfg-eth0).
Yes, I noticed the same with it not being a problem on CentOS 5.5, but it is an issue on Fedora, RHEL6 and Scientific Linux 6. I know that udev has replaced the functions traditionally handled by HAL in older distro releases. It is unusual though because CentOS 5 does have a “/etc/udev” subdirectory which I found strange since there is no udev daemon on my CentOS installations.
Great post. It works. Thanks a lot.
I should add, that the /etc/hostname should be empty, beside the HWADDR on ifcfg-eth0; the udev file trick is good for debian related distros now
thanks!! it’s work!
Nice advice! I could get around the issue.:)
Thank you, awalrath! This helped me a lot!
Patrick
Merci Beaucoup !
you´ve really helped
Thank you kindly :D
Thanks it saved lot of time..
A very enlightening article. thanks a lot !
Thank you very much!!! Your post saved me a lot of time, good job
saved me a bunch of frustration. Thanks for the post and thanks commenters for the tip on deleting that file. nice.
Really a very helpful and informative post; this helped a lot and save my time.
Thanks Indeed.
Thanks for posting. Helped me out when I was banging my head against a wall. I was fiddling with dhcpd.conf on VMware. In other words, nowhere near the solution.
Thank you for this – helped me with a cloned VM.
Thank you so much for this post!! Im studying for the RHCSA exam and had issues with practicing cloning a machine
Excellent job…my problem fixed…thanks
Excellent, thanks. Fixed my issue after cloning a VM in KVM/CentOS 6.
Great work!
I credited you on my blog, which explains how to solve the same problem using cloned templates in vCenter 5.
useless post!! you are said that what you stupid need is to REMOVE 70-persistent-net.rules.. as
ifcfg-eth0 DOES eth-mac mapping !
Worked for me! Thanks for writing this article!
excellent post ! ….this helped a lot !
Thanks a lot! very helpful
Great fix!!!
what about REHL5?
I do not believe this is an issue for 5. I just encountered EXACTLY this problem with CentOS 6.3. I have been doing drive clones of many different prior versions of RH Linuces and this was a brand new glitch. This article was a life-saver for me.
Thanks that waorked for me !!!!!!!!!1
Yeeess ! Thanks a lot !
Merci beaucoup :)
A most excellent post and a life saver. Thanks. I was completely stumped by this problem until I found this post. I have been using real computers, not virtual machines and the same issue applies here too. Thanks Aaron!!!!!
Another thumbs up for this post. I just finished deploying our first 4 RHEL 6.3 virtual machines and noticed none of them had an ETH0 listed when running ifconfig. The configuration had been saved from the install and the interface was there, just not online.
Not sure if this is related to the VMware tools install or not, but this post definitely helped me find the problem, the “ONBOOT” option was set to no. A quick change and I’ve got some happy apps guys.
nice one
Thanks so much buddy for the article. Helped a lot :)
John, Thx! Deleted and rebooted, fixed it
Just want to say thanks like all these other people! wheres the donate button?!?!
Seriously thanks so much. Also, thanks allen for the delete/reboot tip to regenerate the file all together!