Clone a template without cloning its identity

short · 30 min · Objective 1.7

Task

Build a template, clone it the naive way and observe the shared identity that causes confusing failures, then do it properly with generalisation. Along the way, see why a snapshot is not a backup.

Steps

  1. Take the template guest and record its identity: SSH host key fingerprint (ssh-keygen -lf), /etc/machine-id, and any DHCP client identifier. Keep a copy of its public host key on the host as template-hostkey.pub (from the guest's /etc/ssh/ssh_host_ed25519_key.pub) -- after step 4 the template will not have one to compare against.
  2. Clone it naively WITHOUT generalising first: virt-clone --original template --name clone --auto-clone. Boot the clone.
  3. Compare the clone's SSH host key and machine-id with the template's. Confirm they are identical, and explain the concrete failures this causes: SSH host-key collisions, and address clashes wherever a DHCP client identifies itself by an identifier derived from the machine-id -- DHCPv6 always, DHCPv4 when the client is configured that way. (virt-clone does give the clone new MAC addresses, so MAC-keyed DHCPv4 is not the problem.)
  4. Destroy the naive clone. Now shut the template down -- virt-sysprep edits the disk image and must not run under a live guest -- generalise it with virt-sysprep -d template, and confirm it removed the host keys, machine-id and logs.
  5. Clone the generalised template the same way, boot it, and confirm the new machine generates its own host key and machine-id on first boot. Copy its public host key to the host as clone-hostkey.pub.
  6. Take a snapshot of the running clone with virsh snapshot-create-as, make a change, and revert. Confirm the revert worked.
  7. State why that snapshot is not a backup: check where it lives with qemu-img info and confirm it is on the same storage as the VM.

Verify

# after generalising and re-cloning:
diff <(ssh-keygen -lf template-hostkey.pub) <(ssh-keygen -lf clone-hostkey.pub) \
  && echo "SAME KEY -- generalisation failed" || echo "keys differ, good"
virsh snapshot-list clone | head
qemu-img info --force-share /var/lib/libvirt/images/clone.qcow2 | grep -iA3 'snapshot list'   # the snapshot lives INSIDE the VM's own file

The key comparison must show the keys DIFFER after proper generalisation. If they match, virt-sysprep did not run or ran on the wrong image -- which is exactly the state that produces fifty machines an attacker can impersonate as one.

Notes

virt-sysprep is the step people skip because everything appears to work without it. The failures it prevents -- shared host keys, colliding machine-ids, duplicate DHCP leases -- none point back at cloning as the cause, which is why they are so time-consuming to diagnose.

This is an independent study companion for CompTIA Linux+ and is not produced by or endorsed by CompTIA.