Wednesday, March 14, 2012

"device eth0 does not seem to be present, delaying initialization" Error CentOS 6.2 + VMware Clone

CentOS 6.2 Cloned VM are having this issue 

# ls /sys/class/net
eth1 lo

There is a device manager, udev, which stores the settings from the NIC of the vm prior to the cloning? process.? When you clone a vm it also changes the mac address of the NIC and as a result the vm sees it as a new NIC and assigns it to /dev/eth1.

As a result, we now have to edit the udev config file as well as the ifcfg-eth0 file to get the newly update virtual NIC card to operate on the eth0 device.

1. Delete 70-persistent-net.rules which is under /etc/udev/rules.d/ and reboot the machine

OR


First, edit: /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 0x8086:0x100f (e1000)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:be:00:30", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x100f (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:be:00:32", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"


Delete or comment the first SUBSYSTEM entry in the file.

Update the 'eth1' attribute in the remaining entry to 'eth0'

Edit /etc/sysconfig/network-scripts/ifcfg-eth0
Change the HWADDR to match the new mac address listed in the newly edited 70-persistent-net.rules file. eg in my case 00:50:56:be:00:32

like
DEVICE="eth0"
NM_CONTROLLED="yes"
ONBOOT=yes
HWADDR=00:50:56:BE:00:32
BOOTPROTO=static
 


Reeboot the machine.


12 comments:

  1. Many thanks - trawled for hours and stumbled across this. Its always the easiest solutions that you tend to dismiss offhand!

    ReplyDelete
  2. You made my day

    ReplyDelete
  3. You can also rename or delete the file: /etc/udev/rules.d/70-persistent-net.rules then reboot.

    It will rebuild the file with the new mac addresses.

    ReplyDelete
  4. Hi, your page helped out. We had a VM for our master which holds all our hosted vm's which after importing the master itself into the database and then rebooting that master, came up with no network. After using terminal client in Ubuntu we were able to vnc to the running VM and followed your method above and it worked.

    Thanks for creating this page! It can be a life saver.

    Eli
    Tier1 Hosting Solutions

    ReplyDelete
  5. So, this is just one more complication added which earlier UNIXes didn't have nor need. Is there a way to turn on this udev device hardware caching so that cloning of VMs would require less manual modification?

    ReplyDelete
    Replies
    1. I meant "off", "turn off", is there a way to turn this off altogether?

      Delete
  6. What I did was delete the contents of /etc/udev/rules.d/70-persistent-net.rules and comment out the HWADDR in the /etc/sysconfig/network-scripts/ifcfg-eth0 file. Then I created a template of this VM as the Master and used that to clone new VM's. When the new VM is cloned at reboot it will recreate the 70-persistent-net.rules with the proper interfaces and MAC addresses defined and the NIC interfaces will come up just fine. No manual intervention required after cloning.

    ReplyDelete
  7. Just deleting the 70-persistent-net.rules file worked for me. Thanks :)

    ReplyDelete
  8. Hey, you copied this from http://www.ryanchapin.com/fv-b-4-655/Cloned-VMware-CentOS6-Server-and--quot-device-eth0-does-not-seem-to-be-present--delaying-initialization-quot--Error-.html

    You should give the guy credit instead of letting people think it's your knowledge.

    ReplyDelete
  9. Your instructions were the only ones that worked for me. Thanks a lot!

    ReplyDelete