Linux VMware cannot start eth0 Nic After cloning, vmwareeth0

Linux VMware cannot start eth0 Nic After cloning, vmwareeth0

 

Reference:

In VMware LINUX, the following error occurs: Device eth0 does not seem to be present, delaying initialization. Solution: VMWare clones and copies eth0 be present and cannot find solution vmware clone Nic
No eth0 Nic information is displayed when ifconfig is used in LINUX in VMware!
When the cloned virtual machine is used, the eth0 Nic in the basic system is lost to the new system. If ifconfig-a is used, only eth1 is found. Because the network configuration of the basic system is based on eth0, and eth1 does not have network-related configuration, in this case, the network in the virtual machine must be normal, and only the network configuration of eth1 should be added, in this way, it is inconvenient to modify the NIC configuration every time you perform multiple Linux system tests. Furthermore, if the clone VM continues to clone or copy a new Vm, the nic id will be automatically added with 1 for each clone (the second clone will change to eth2 ), dmesg shows that the kernel only recognizes the network adapter eth0.
Cause analysis:Many Linux distribution usesUdev dynamically manages Device FilesAnd name the device based on the device information. For example, in Debian etch, udev identifies the NIC during system boot and records the mac address and nic name in the udev rule script. VMware automatically generates the mac address of the VM. In this way, because the VM of the basic system has recorded that the mac address of the NIC of the VM corresponds to eth0 of the NIC, the mac address of the cloned VM is changed, udev automatically maps the mac to the network adapter eth1. Similarly, udev records all the relationships between recognized mac addresses and network card names. Therefore, each clone Nic name is automatically added with 1. In fact, the kernel only recognizes one network card, the network configuration related to the NIC name has not changed.
Solution:Network search finds that In Debian etch, udev stores the correspondence between mac and nic name in/etc/udev/rules. d/z25_persistent-net.rules, In the cloned virtual machine as long as you delete the line with NAME = "eth0" and restart the system.
For example, delete the following two lines in Debian etch:
# PCI device 0x1022: 0x2000 (pcnet32) SUBSYSTEM = "net", DRIVERS = "? * ", ATTRS {address}
= "00: 0c: 29: 4c: 46: 01", NAME = "eth0" in myFedora9Under/etc/udev/rules. d70-persistent-net.rulesDelete the following content:
# Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rule written by anaconda) SUBSYSTEM = "net", ACTION = "add", DRIVERS = "? * ", ATTR {address} =" 00: 0c: 29: ad: 06: 2a ", ATTR {type} =" 1 ", KERNEL = "eth *", NAME = "eth0"
ThenEth1Change "eth1" of the corresponding row to "eth0.
In additionOne way is to put the content in itBothDelete the file, and then restart it. The system also discovers the hardware of the NIC and generates the file again. OK!

 

The above is a solution from the Internet. One of them is not clear, that is, the/etc/udev/rules is deleted. after d/70-persistent-net.rules, You need to reconfigure/etc/sysconfig/network-script/ifcfg-eth0. The ifcfg-eth0 file content is as follows (my ):

You need to modify HWADDR (mac address) and IPADDR (IP address ). IPADDR can be modified as needed. HWADDR automatically generates the hardware address when VMware starts the Virtual Machine and records it in/etc/udev/rules. d/70-persistent-net.rules file. Therefore, when/etc/udev/rules is deleted. d/70-persistent-net.rules file, modify ipaddr in the ifcfg-eth0 file to address your needs and delete UUID (delete UUID optional reason see http://www.zhihu.com/question/28670717), and then restart the system, at this time ifconfig cannot see eth0, the following operation is to change eth1 in the automatically generated 70-persistent-net.rules to eth0, and then copy the corresponding hardware address of the record to the hwaddr of the ifcfg-eth0. Restart the system. ifconfig should be normal.