Clone the source powered off. A live clone copies a running system mid-write — databases, logs, and anything with state on disk can come across inconsistent, and the clone inherits whatever the original was doing at that moment. Power it off, clone it, and the copy is clean. If the source cannot be powered off, take a snapshot and clone from that, and treat the result with suspicion until it has been verified.
Boot the clone isolated first. Disconnected from the production network, or on an isolated port group, with no route to the original. The first boot is when the clone announces itself — DHCP requests, agent check-ins, monitoring heartbeats — and if it does that on the production network before it is unique, it announces itself as the original. Do the identity work offline, then connect it. This one habit prevents most of the damage on this page.

Set it, in all three places, and check all three.
hostnamectl set-hostname web02.example.com
That sets the static hostname, which is what matters. Then check /etc/hostname holds the same short name, and /etc/hosts has the new name against 127.0.0.1 — an /etc/hosts that still maps the old name to localhost is how a clone keeps answering to the original’s name in its own logs, and how sudo starts complaining that it cannot resolve the host. Verify with hostnamectl and hostname -f: the first shows the name, the second shows the name resolves. If the second fails, /etc/hosts is the usual culprit.
RHEL 6/7 note: the same idea, older tools — /etc/sysconfig/network held the hostname on RHEL 6, and hostnamectl exists from RHEL 7 onward. The file to check is the same one your version actually reads, and on a fleet with hundreds of RHEL 6/7 boxes, that distinction is worth remembering.

The machine-id is the system’s identity to everything that manages it. /etc/machine-id is a single UUID that systemd, the journal, D-Bus, and — critically — management tools use to tell one host from another. Two hosts with the same machine-id are, to those tools, the same host. The journal on both will carry the same boot ID space, and anything that inventories by machine-id will merge them, overwrite one with the other, or flap between them.
rm /etc/machine-id
systemd-machine-id-setup
cat /etc/machine-id
That is the whole fix: remove the copied ID, generate a fresh one, verify it is different from the original’s. Do it before the clone’s first real boot if you can, and definitely before any agent registers. On RHEL 7 the same file exists and the same command works; on RHEL 6 there is no machine-id at all, which is one of the few ways cloning a RHEL 6 box is simpler.
The related one: D-Bus. If /var/lib/dbus/machine-id exists as a separate file (older setups, some images), it should match /etc/machine-id or be a symlink to it — check, and fix it the same way. A mismatched D-Bus ID is a quieter version of the same bug.

Regenerate them, or every SSH client will warn — or worse, will not warn. The host keys in /etc/ssh/ssh_host_* identify the server to SSH clients. A clone carries the original’s keys, so a client connecting to the clone sees the original’s key, and a client that has the original’s key cached connects to the clone without a word. That is a man-in-the-middle condition built by your own cloning process, and it is also the reason SSH clients start shouting “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED” when the keys are finally fixed on one box but not the other.
rm -f /etc/ssh/ssh_host_*
ssh-keygen -A
systemctl restart sshd
ssh-keygen -A regenerates every missing host key type (RSA, ECDSA, Ed25519) in one command, and the restart makes sshd pick them up. Verify with ssh-keyscan -t ed25519 <clone> from another host, and compare the fingerprint with the original’s — they must differ. Then tell your users: the first connection to the clone will prompt for the new key, and that prompt is correct, not an attack. A fingerprint they can verify beats a warning they learn to ignore.
While you are here: check /root/.ssh/authorized_keys and any service accounts’ keys. The clone inherits the original’s authorized keys, which is usually what you want for access — but if the original had a key that should not exist on the clone (a deployment key, a backup key, a person who left), this is the moment to remove it, not six months from now.

MAC address. vSphere generates a new MAC for a cloned VM by default — check that it did. If the clone was made with the MAC set to manual, or copied from a template with a fixed MAC, two VMs now share a MAC on the same network, and the symptom is the classic one: intermittent connectivity, ARP flapping, packets arriving at the wrong VM, and nobody believing the network is at fault because “nothing changed”. Check with ip link, and compare with the original. If they match, regenerate the MAC in vSphere and reboot the clone.
IP address. If the original used DHCP, the clone will request a lease — and the DHCP server may hand it the original’s address, because the request can carry the original’s client identifier. Clear the DHCP lease state (/var/lib/dhclient/ on older systems, NetworkManager’s lease handling on newer ones) and confirm the clone gets its own address, then confirm it is the address you expect with ip addr. If the original used a static address, change it before the clone touches the production network — two hosts on one IP is the fastest way to take both of them down. On RHEL 9/10, do it with nmcli or by editing the NetworkManager connection, not by editing ifcfg files that no longer exist.
Interface names. Predictable interface names (enp0s3, ens192) are derived from hardware position, and a clone on different virtual hardware can rename its interfaces — the connection profile follows the old name and the new interface has no configuration. Check ip link against nmcli connection show: if a connection is bound to an interface name that no longer exists, rebind it. On RHEL 6/7, the old 70-persistent-net.rules could pin a MAC to a name — if it exists on the clone, delete it and let the names regenerate.

Filesystem UUIDs in /etc/fstab. A block-level clone copies filesystem UUIDs along with the data, so the clone’s fstab — which mounts by UUID — still works, and still points at the clone’s own disks. That is correct, and it is also the trap: if both the original and the clone ever share storage, or if a disk is moved between them, the duplicate UUIDs make the wrong disk mountable as the right one. On a VMware clone with its own virtual disks, this is normally safe — but check blkid against /etc/fstab and know which UUID belongs to which disk before you assume it.
The VMware BIOS UUID. vSphere assigns each VM a BIOS UUID, and the guest can see it (via dmidecode -s system-uuid). A clone gets a new one by default; if it was preserved, anything that licenses or inventories by that UUID — some commercial software, some monitoring — will confuse the two. Check it differs from the original’s.
GRUB. The bootloader usually needs nothing after a clone, but if the clone’s disk layout changed (different controller, different disk order), verify the system boots cleanly and grubby --default-kernel points at a kernel that exists. A clone that boots is a clone that has already passed this test; a clone that does not is usually a disk-order problem, not a GRUB problem.

This is the section that separates a checklist from a hostname change. The clone inherited every agent, subscription, and registration the original ever made, and each one will now report as the original until it is re-registered — or, worse, will overwrite the original’s record with the clone’s data.
Patching and inventory. Red Hat Subscription Manager (subscription-manager), Satellite, Spacewalk, or any CMDB agent: unregister the clone and register it as itself, with its new hostname and machine-id. A clone that keeps the original’s subscription will consume the original’s entitlement and report the original’s patch state as its own — which is how a host ends up “fully patched” in the console while running a kernel from two years ago.
Monitoring and backup. Nagios, Zabbix, and their agents; Commvault, NetBackup, and any backup client: re-register with the new identity, and check the central console shows two hosts, not one host with a flapping identity. The backup one is the dangerous version: a clone that backs up as the original can overwrite the original’s backup set, and a restore from that set is a restore of the wrong machine.
Kerberos and certificates. A keytab (/etc/krb5.keytab) is identity-bound — regenerate it for the new hostname, or the clone will fail authentication as the original. TLS certificates with the original’s name in them need reissuing for the clone’s name. And any cron job that calls a central system by hostname needs its own review: a clone running the original’s cron is a clone doing the original’s work twice, or doing it against the original’s data.
Time. Check chrony is running and synchronised (chronyc tracking) — a clone can inherit a stale clock, and a clock that is wrong by minutes will break Kerberos, TLS, and log correlation all at once, in ways that look like three separate problems.

A vSphere customization specification can set the hostname, the IP address, the DNS domain, and the timezone during cloning, and it does those things well. Use it — it is the difference between a clone that needs an hour of manual work and a clone that needs ten minutes. But know its limits: a customization spec does not regenerate SSH host keys, does not reset the machine-id, does not re-register agents, and does not touch keytabs or certificates. The spec handles the network identity; the rest of this checklist is still yours.
Templates, not clones, for repeat builds. If you are cloning the same source more than twice, stop cloning and build a template: a powered-off, generalized VM — hostname cleared, machine-id removed, SSH keys removed, logs cleared, cloud-init or a customization spec ready — that every new server is deployed from. A template is a clone with the identity work already done, once, instead of once per server. And if your fleet is large enough to have a template, it is large enough for cloud-init, which does the first-boot identity work (hostname, keys, users, network) from a single configuration, and does it the same way every time.
The same checklist, other hypervisors. KVM and virt-clone, Hyper-V, cloud images: the hypervisor changes, the identity items do not. Hostname, machine-id, SSH keys, MAC, IP, agents, keytab, certificates — the list is the same because the operating system is the same, and the operating system is what was copied.