Solution to NIC loading failure after CentOS cloning
I. Fault symptom:
[Root @ c1node01 ~] # Service network restart
Shutting downloopback insterface: [OK]
Bringing uploopback insterface: [OK]
Bringing upinterface eth0: Device eth0 does notseem to be present, delaying initialization. [FAILED]
Ii. Solution
Method 1:
Solution:
[Root @ c1node01 ~] # Rm-rf/etc/udev/rules. d/70-persistent-net.rules
[Root @ c1node01 ~] # Reboot ..................
[Root @ c1node01 ~] # Service network restart
Shutting downloopback insterface: [OK]
Bringing uploopback insterface: [OK]
Bringing up interfaceeth0: [OK]
Method 2:
After installing a centos virtual machine, copy another one. After the machine is started, the NIC cannot start properly. The error message is: Device eth0 does not seem to be present,
Delayinginitialization
Solution: # mv/etc/sysconfig/network-scripts/ifcfg-eth0/etc/sysconfig/network-scripts/ifcfg-eth1
Vim/etc/sysconfig/network-scripts/ifcfg-eth1
Modify DEVICE = "eth0"
For DEVICE = "eth1"
Restart the NIC and try again.
Method 3:
Similar things happen in RHEL5, because the MAC of the VM will be re-generated, but the MAC of the operating system is written in ifcfg-ethx, resulting in inconsistency, so the network interface cannot be started, in RHEL5, you can use kudzu or comment out the MAC field of the NIC configuration file to solve this problem. However, in RHEL6, kudzu has been replaced by the hal service. Although lspci can recognize the NIC normally, it cannot start the service using/etc/init. d/networkrestart. Try to annotate the mac field of the ifcfg-eth0 or report an error. Check the udev rules and find the problem.
[Root @ Oracle ~] # 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.
# Net device () (custom name provided by external tool)
SUBSYSTEM = "net", ACTION = "add", DRIVERS = "? * ", ATTR {address} =" 08: 00: 27: 16: 31: 11 ", ATTR {type} =" 1 ″, KERNEL = "eth *", NAME = "eth0 ″
# Net device ()
SUBSYSTEM = "net", ACTION = "add", DRIVERS = "? * ", ATTR {address} =" 08: 00: 27: 32: 66: 63 ", ATTR {type} =" 1 ″, KERNEL = "eth *", NAME = "eth1 ″
[Root @ Oracle ~] #
UDEV used the cloned MAC as the eth0MAC of the current virtual machine, and the re-generated 08: 00: 27: 32: 66: 63 is the MAC of eth1.
To solve this problem, you only need to delete the old UDEV configuration and modify it:
[Root @ Oracle ~] # 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.
# Net device () (custom name provided by external tool)
SUBSYSTEM = "net", ACTION = "add", DRIVERS = "? * ", ATTR {address} =" 08: 00: 27: 32: 66: 63 ", ATTR {type} =" 1 ″, KERNEL = "eth *", NAME = "eth0 ″
RestartNetworkSometimes the Service may not work, and restarting the system is all about it.OK! Tried multiple times!
[Root @ Oracle ~] #/Etc/init. d/network restart
Shutting down interface eth0: [OK]
Shutting down loopback interface: [OK]
Bringing up loopback interface: [OK]
Bringing up interface eth0: [OK]
If it doesn't work, restart the reboot instance. This is how I solve the problem.