Traps of the VMware clone function

This is not a good time. I have been busy for a whole day. I will remember a problem in the morning for future reference.

I am going to install another virtual machine today, so I am too troubled to suddenly think of using one of VMware's functions to clone one. There is already a redhat6.1. let's just do it. After the successful completion, I will be able to easily log on, this virtual machine is configured with two NICs, one connecting to the Intranet (192. 168. ***. * **), a local area network (172. 17. ***. ***). These are all configured on the prototype and should be directly usable After cloning. I knocked on ifconfig, but it was troublesome. I only showed the loose (L0). What happened?
Ifconfig-A is even more strange. Besides the loop, there are also eth2 and ech3 ports. What is going on? It should be eth0 and eth1. Google.

The reason is as follows:

RedHat uses udev to dynamically manage device files and persistently name them based on device information. Udev identifies the NIC during system boot, and records the MAC address and nic name in the udev rule script. For new virtual machines, VMWare will automatically generate a MAC address for the Virtual Machine's Nic. When you clone or reinstall the Virtual Machine Software, because you used the previous system virtual hard disk information, the system already has eth0 and eth1 information. For the new two NICs, udev will automatically name them eth2 and eth3 (accumulation principle ), therefore, after your system is started, you can use ifconfig to see the names of eth2 and eth3. At this time, the configuration files of eth0 and eth1 are still in/etc/sysconfig/network-script/. Naturally, eth3 and eth4 cannot be started, which is why only the loop interface is normal.

Solution:

Solution: 1. Set/etc/udev/rules. d/70-persistent-net.rules
All information is deleted, so that the system can identify and re-write the data.

 
2. Delete the Mac information in eth0 and ech1 from/etc/sysconfig/network-script/, and re-allocate VMware.

After modification, reboot or restart the NIC: Service
Network restart. After the network restart is completed, you will find that your beloved Nic is finally back, haha.