Although there are many solutions to this problem on the Internet, I have decided to repeat the solution myself, repeating the new function of VMware workstation 15 in repetition of the knowledge.

when a virtual machine for centos7.x series system is cloned using VMware workstation, whether the link clone or the complete clone, it is very likely that the following network card will not boot:

note: this is not a problem in VMware workstation 15 for current workstation testing, and I will explain why not and why I am writing for this article later in this post.

1 ifup ens33
2 
3 Error:Connection activation failed: No suitable device found for this connection

the problem occurs because MAC addresses are the same, resulting in conflicts

clone virtual machine, default its network card MAC address is still the previous template machine MAC, so the MAC address will conflict, when the system USES NetworkManager to manage the network card

NetworkManager does not allow MAC addresses to be the same, which leads to the network card directly unable to get up, but centos6.x does not because it USES the network for management. 1. If you do not plan to use NetworkManager, simply close the NetworkManager

1 systemctl stop NetworkManager      # 停止NetworkManager   
2 systemctl mask NetworkManager　　　 # 禁用NetworkManager，类似Windows的禁用
3 systemctl disable NetworkManager   # 开机不启动

2. Change MAC address

1) delete the previous network card directly through the virtual machine management interface of VMware workstation, add again, or click advanced, modify the MAC address and template machine are different, as shown in the figure below:

2) then start the system, modify the network card configuration file /etc/sysconfig/network-scripts/ ifcfg-xxx

The parameter HWADDR in

= new nic MAC

3) if there is a 70-persistent net-rules file under /etc/udev/rules.d/ directory, then change the MAC address of the network card inside to the new network card MAC

why is it that if /etc/udev/rules.d/ exists under the 70-persistent net.rules file?

because if the CentOS7 system is installed in the kernel with net.ifnames=0 biosdevname=0, that means not CentOS7 network card naming rules, but the traditional

eth0… Ethn does not have this file on the system by default, but it still exists on any other installed system, even though it has been changed to the traditional network card naming rules again after installation.