VM clones in production are risky business. Every NS8 instance generates values that are expected to be globally unique: systemd’s machine-id, WireGuard keys (used for inter-node VPN in a cluster), SSH host keys, TLS certificates, subscription/registration tokens, and so on. Cloning a VM — whether full or linked — duplicates these values verbatim unless you take deliberate steps to regenerate them afterward.
The official NS8 .qcow2/.vmdk image handles this correctly: it ships “clean” (no identity baked in), and on first boot it runs a cloud-init-style procedure that generates all these unique tokens fresh. Once that first boot has happened, the instance is “personalized” — cloning it at that point (full or linked, doesn’t matter) will duplicate the identity, and you’ll end up with two nodes that think they’re the same node, or WireGuard keys colliding if you ever join them to the same cluster.
So to directly answer the full-clone-vs-linked-clone question: it’s the wrong question for NS8. The Proxmox-level tradeoffs (linked clones being faster to spin up and space-efficient, but dependent on the base snapshot staying intact; full clones being slower to create but independent and safer to keep long-term) matter for OS templates in general, but they’re moot here because you shouldn’t be cloning a personalized NS8 instance either way.
If you want a repeatable deployment process:
- Start from the pre-built image every time (download fresh, or keep a pristine, never-booted copy as your “template”), and let first-boot do its job on each new VM.
- The image also supports cloud-init, so for Proxmox specifically you don’t even need to touch the VM by hand: attach a cloud-init drive with your network config, SSH keys, hostname, etc., and let it handle per-VM customization on top of the first-boot identity generation. That’s the supported path if you want templated, repeatable provisioning without falling into the cloning trap.
- Don’t boot the “template” itself and then clone it — that’s exactly the scenario that leaks unique identity into your clones.
If you have a concrete reason you need snapshot-based cloning (e.g. testing), that’s a different use case than production provisioning — just make sure any clone destined for real use gets its identity regenerated (new machine-id, new WireGuard keys, re-run of the first-boot logic) before it joins anything.