When you clone or ‘deploy from template’ a linux virtual machine on Vmware, specifically Red Hat based linux such as CentOS, you need additional steps on the cloned machine to make it work. The obvious settings you need to change are the IP address and hostname. But changing those settings is not enough. You also need to change other parameters.

When you clone a linux machine, the hardware address (or MAC address) of the NIC changes, which is correct — the cloned machine should never have the same MAC address as the source. However, the new MAC address is assigned to eth1, not eth0. The eth0 is still assigned the MAC address of the source, although it is commented out in udev’s network persistent file, so it’s not active.

When you cloned a linux machine and noticed that the network does not work, it is probably because you assigned the new IP address to eth0 (which is not active). You can use eth1 and assign the new IP address on that interface. However, I usually want to use eth0 to make it clean and simple. You can easily switch back to eth0 by editing the file /etc/udev/rules.d/70-persistent-net.rules. Edit the string that starts with SUBSYSTEM, remove or comment out the line for eth1, uncomment the line for eth0, and replace the ATTR(address) for eth0 to get the MAC address from eth1. Here’s a sample edited file:

# 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.

# PCI device 0x8086:0x100f (e1000)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:60:66:88:00:02",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Now edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file to make sure that the DEVICE is eth0, the BOOTPROTO is static, and the HWADDR matches the ATTR{address} for eth0 in the 70-persistent-net.rules file.

Restart the network by issuing the command “service network restart” or you can reboot the system.

There are times when you need to perform hardware maintenance (such as adding a new Network Interface Card [NIC]) on VMware hosts, or the host simply disconnects from vCenter.  The only way to perform maintenance is to shutdown or reboot the hosts.  To minimize damage, here’s the procedure I use:

1. Run vSphere client on the workstation.  Do not use the vSphere client on the servers. The reason being – a server might be a virtual machine (VM) which will go down.
2. Using vSphere client, connect to VMware host, *not* the vCenter server.
3. Login as user root.
4. Shutdown all the VM’s, by right clicking the VM, selecting Power, Shutdown Guest.  This is faster than logging in to each machine using RDP and shutting it down.  The vmtools though have to be up to date, or else the Shutdown Guest option will be grayed out. If Shutdown Guest is grayed out, you need to login to the VM to shut it down.  Performing “Power Off” on the VM should be the last resort.
5. Once all the VM’s are powered down, right click on the VMware host and select Enter Maintenance Mode.
6. Go to the console of the VMware host, and press Alt-F11 to get the login prompt.
7. Login as root.
8. Issue the command “shutdown -h now” to power down the host.  If you just want to reboot, issue the command “shutdown -r now”.
9. Wait until the machine is powered off.
10. Perform maintenance.
11. Power on the VMware host.  Look for any problems on the screen.  The equivalent of blue screen in VMware is purple screen.  When there’s a purple screen, that means there is something very wrong.
12. When the VMware host is all booted up, go back to your workstation, and connect using vSphere client to the VMware host.
13. Right click on the Vmware host first, and select “Exit Maintenance Mode”
14. Power On all the VM’s.

If there are multiple VMware hosts, and Vmotion is licensed and enabled (i.e. Enterprise License), you can vmotion VMs to the other hosts, and perform maintenance.  When the host gets back, you can vmotion back the VM’s to the host, and do the same maintenance on the other.