Of course, a cloned VM is another computer, and like any new computer in a network, it must have a unique name within the network domain it is part of.

A cloned VM must have a unique IP address within the network domain it is part of. This is not a problem in general if DHCP is used to assign addresses; when the VM boots the DHCP server will assign it an IP address. If the cloned VM had a static IP address, the clone must be given an unused IP address before being booted.

In some cases, the MAC address of a cloned VM's virtual network interface is recorded in the network configuration files. After the VM is cloned, the new cloned VM has a different MAC address. Therefore, when started, the network does not come up automatically.

Some Linux distributions use udev rules to remember the MAC address of each network interface, and persist a name for that interface. This is intended so that the same physical NIC always maps to the same ethn interface, which is particularly useful with removable NICs (like laptops). But this behavior is problematic in the context of Virtual Machines. For example, if you configure two virtual NICs when you install a VM, and then shut it down and remove the first NIC, on reboot XenCenter shows just one NIC, but calls it eth0. Meanwhile the VM is deliberately forcing this to be eth1. The result is that networking doesn't work.

If the VM uses persistent names, the best thing to do is to turn these rules off. If for some reason you do not want to turn persistent names off, be aware that you will need to reconfigure networking inside the VM in the usual way, and the information shown in XenCenter will be out of synch with reality.