Clone a template without cloning its identity
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
- Take the template guest and record its identity: SSH host key fingerprint (
ssh-keygen -lf),/etc/machine-id, and any DHCP client identifier. - Clone it naively with
virt-cloneWITHOUT generalising first. Boot the clone. - Compare the clone's SSH host key and machine-id with the template's. Confirm they are identical, and explain the two concrete failures this causes: SSH host-key collisions and DHCP handing the same address to different hosts.
- Destroy the naive clone. Now generalise the template with
virt-sysprep -d templateand confirm it removed the host keys, machine-id and logs. - Clone the generalised template and boot it. Confirm the new machine generates its own host key and machine-id on first boot.
- Take a snapshot of the running clone with
virsh snapshot-create-as, make a change, and revert. Confirm the revert worked. - State why that snapshot is not a backup: check where it lives with
qemu-img infoand 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 /var/lib/libvirt/images/clone.qcow2 | grep -i backing
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.