When I built the storage pools on my cluster nodes, the most consequential decision was not the drive, the layout, or any of the tuning options. It was the name. Both pools are called tank. Not tank1 and tank2, not a name derived from each node's hostname, not anything descriptive. The same word on every node.
Every instinct from general software engineering says this is wrong. Names should be unique. Names should tell you which thing you are looking at. Two different pools on two different machines with the same name feels like a collision waiting to happen.
Those instincts are correct for identifiers that live in one namespace. They are exactly backwards for identifiers that define equivalent slots on interchangeable machines, and a cluster's storage is the second kind.
Why the same name is the whole feature
Proxmox replication and migration move a guest's disk from a pool on one node to a pool on another. The guest's configuration names its storage once: this container's root disk lives on storage tank-local, which maps to pool tank. When the guest moves, or when its replica activates on the other node, the configuration does not change. It says tank, the receiving node has a tank, everything resolves.
Name the pools tank1 and tank2 instead and every movement between nodes becomes a translation problem. The replication has a working source and a mismatched destination. The config that says tank1 lands on a node that only knows tank2. Tools that assume the name resolves identically everywhere, which is most of them, either refuse or need per-move hand-holding. You have taken a single-command operation and given it a lookup table to maintain forever.
The rule generalizes beyond storage. Any time machines are supposed to be interchangeable, the resources that make them interchangeable must be indistinguishable. Same pool name, same dataset structure underneath it, compatible layout, same platform version. The node's own hostname is where individuality belongs; the slots a workload plugs into should be identical everywhere, like electrical sockets.
What it looks like when it works
With both pools named tank and replication scheduled, moving a container between nodes is one command with no storage arguments at all. The failover case is even better: the cluster's HA layer restarts a guest on the surviving node from the replicated copy without consulting anyone about where the disk lives. It knows where the disk lives. It lives on tank, the same as everywhere.
I tested that failover deliberately, powered a node down and watched the workload come back on its partner in about ninety seconds. That test, and the timeline of what happens in those ninety seconds, is next week's story. The point for today is that none of it works without the naming convention underneath.
Renaming later is the expensive path
If you get this wrong at creation, fixing it is not a rename in the friendly sense. A ZFS pool's name is baked into the mounting structure, the hypervisor's storage registrations, every guest config referencing it, and any replication chains already flowing. Renaming means exporting the pool, re-importing under a new name, and re-pointing everything that referenced the old one, with replication state broken and rebuilt from scratch. On a live node that is an afternoon of careful work in the best case.
Thirty seconds of deciding "every pool is called tank" at build time buys out all of that. Thirty seconds against an afternoon of careful work is not a close call.
The pool build itself, drive selection through the option-by-option rationale, is in Tuesday's post if you missed it. Together they are two halves of one idea: build each node's storage identically, and the cluster stops being three computers and starts being one system.
