Home > Linux, VMware > Cloned Red Hat/CentOS/Scientific Linux Virtual Machines and “Device eth0 does not seem to be present” Message

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!

Advertisements
Categories: Linux, VMware Tags: ,
  1. Jeffrey Bride
    February 28, 2011 at 3:08 am

    Nice post ! …. this helped a lot !

  2. alen
    February 28, 2011 at 3:29 pm

    you can also simply delete the /etc/udev/rules.d/70-persistent-net.rules file and it will be regenerated on reboot.

    • February 28, 2011 at 7:32 pm

      Thanks for the tip, Alen.

  3. John Breeden
    March 13, 2011 at 8:08 pm

    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

  4. lovetide
    March 30, 2011 at 3:32 am

    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).

    • March 30, 2011 at 4:11 am

      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.

  5. tn
    April 9, 2011 at 9:29 pm

    Great post. It works. Thanks a lot.

  6. Felipe Solari
    May 16, 2011 at 4:55 am

    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

  7. Chris
    August 15, 2011 at 4:42 am

    thanks!! it’s work!

  8. August 29, 2011 at 2:01 am

    Nice advice! I could get around the issue.:)

  9. Patrick
    August 30, 2011 at 6:30 pm

    Thank you, awalrath! This helped me a lot!

    Patrick

  10. crecre
    September 23, 2011 at 6:38 am

    Merci Beaucoup !

    you´ve really helped

  11. Harry
    October 31, 2011 at 8:18 pm

    Thank you kindly :D

  12. Chandra
    November 15, 2011 at 9:25 am

    Thanks it saved lot of time..

  13. felahe
    December 1, 2011 at 6:31 pm

    A very enlightening article. thanks a lot !

  14. December 6, 2011 at 4:29 pm

    Thank you very much!!! Your post saved me a lot of time, good job

  15. Anh
    December 7, 2011 at 8:25 pm

    saved me a bunch of frustration. Thanks for the post and thanks commenters for the tip on deleting that file. nice.

  16. Irfan Baba
    December 23, 2011 at 5:33 am

    Really a very helpful and informative post; this helped a lot and save my time.
    Thanks Indeed.

  17. January 6, 2012 at 8:39 pm

    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.

  18. Geeta
    February 9, 2012 at 9:53 pm

    Thank you for this – helped me with a cloned VM.

  19. February 25, 2012 at 2:42 am

    Thank you so much for this post!! Im studying for the RHCSA exam and had issues with practicing cloning a machine

  20. Sayem
    March 7, 2012 at 5:22 am

    Excellent job…my problem fixed…thanks

  21. April 2, 2012 at 3:14 am

    Excellent, thanks. Fixed my issue after cloning a VM in KVM/CentOS 6.

  22. April 13, 2012 at 6:26 am

    Great work!
    I credited you on my blog, which explains how to solve the same problem using cloned templates in vCenter 5.

  23. haha
    June 21, 2012 at 10:09 am

    useless post!! you are said that what you stupid need is to REMOVE 70-persistent-net.rules.. as
    ifcfg-eth0 DOES eth-mac mapping !

  24. July 30, 2012 at 12:27 pm

    Worked for me! Thanks for writing this article!

  25. Ganesh kumar Dubey
    September 21, 2012 at 4:41 am

    excellent post ! ….this helped a lot !

  26. Marcin
    October 12, 2012 at 2:14 am

    Thanks a lot! very helpful

  27. espo
    October 29, 2012 at 8:45 pm

    Great fix!!!

  28. LordISP
    November 2, 2012 at 11:53 am

    what about REHL5?

    • February 8, 2013 at 11:40 pm

      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.

  29. Owiza007
    December 25, 2012 at 2:24 pm

    Thanks that waorked for me !!!!!!!!!1

  30. tomkom
    January 16, 2013 at 2:36 pm

    Yeeess ! Thanks a lot !
    Merci beaucoup :)

  31. February 8, 2013 at 11:45 pm

    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!!!!!

  32. M B
    February 21, 2013 at 8:00 pm

    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.

  33. anil
    April 12, 2013 at 4:28 am

    nice one

  34. April 12, 2013 at 10:39 am

    Thanks so much buddy for the article. Helped a lot :)

  35. Rod
    May 31, 2013 at 1:56 pm

    John, Thx! Deleted and rebooted, fixed it

  36. Cmoney - SLC
    June 7, 2013 at 8:29 pm

    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!

  1. March 8, 2012 at 5:03 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: