Virtual machine lifecycle: templates, snapshots and cloning
In short: Well-run virtual environments build every VM from a hardened template, customise it automatically when deploying, use snapshots only briefly around changes, and retire VMs that are no longer needed. Snapshots are not backups, and forgotten snapshots or VMs waste storage and create risk.
Why the lifecycle matters
Creating a VM takes minutes, which is both the strength and the danger of virtualisation. Without a process you get VM sprawl: hundreds of machines with unknown owners, out-of-date software and wasted storage. Managing the full lifecycle keeps the estate secure and tidy.
Templates and golden images
A template is a master VM that is never switched on for normal use. It contains a patched, hardened operating system, agents (monitoring, backup, security) and standard settings. Every new server is deployed from it, so they all start from the same known-good baseline. Update templates monthly, or rebuild them automatically with tools such as Packer.
When you copy a template, each copy must get a unique identity. On Windows, the template is generalised with Sysprep so each clone gets a new security identifier (SID) and computer name. On Linux, cloud-init or a hypervisor customisation spec sets hostname, network and SSH keys at first boot. Skipping this can cause duplicate names, IP conflicts and domain join problems.
Cloning
| Type | How it works | Good for |
|---|---|---|
| Full clone | Complete independent copy of the disks | Production servers |
| Linked clone | Shares the parent disk and stores only changes | Labs, test and VDI pools where speed and space matter |
| Instant clone | Forks a running VM's memory and disk state | Very fast desktop pools in some VDI products |
Linked clones save space but depend on the parent: if the parent disk is lost or damaged, every child breaks.
Snapshots done right
A snapshot records a VM's disk state, and optionally its memory, at one moment. After the snapshot, new writes go into a separate delta file. Reverting throws away the delta and returns the VM to that moment. This is perfect before a risky change such as a major update:
- Take a snapshot with a clear name, for example "pre-patch 2026-10 by alice".
- Make the change and test the service.
- If it fails, revert. If it works, delete (consolidate) the snapshot within a day or two.
Common mistakes:
- Keeping snapshots for weeks. Delta files grow, slow the VM and can fill a datastore, which stops every VM on it.
- Treating snapshots as backups. They live on the same storage and depend on the base disk.
- Reverting domain controllers or databases carelessly. Rolling back can cause replication or data consistency problems; use the application's supported recovery method.
Retirement
Every VM should have an owner, a purpose and a review date, often stored as tags or custom attributes. When it is no longer needed: confirm with the owner, power it off for a short grace period, take a final backup if required by retention rules, then delete it and remove its DNS records, firewall rules, monitoring and licences.
Tip: run a monthly report of powered-off VMs, VMs without owners and snapshots older than three days. It is one of the cheapest ways to save storage and reduce risk.
Practice
Why should a Windows template be generalised with Sysprep?
What happens to a linked clone if its parent disk is deleted?
Give two reasons not to keep snapshots for a long time.
Key takeaways
- Build every VM from a patched, hardened template.
- Generalise templates (Sysprep, cloud-init) so each clone is unique.
- Full clones are independent; linked clones depend on the parent.
- Snapshots are a short-term undo, not a backup; delete them promptly.
- Tag owners and retire unused VMs to avoid sprawl.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.