vSAN ESA Global Dedup: One Store for the Whole Cluster

vSAN ESA in 9.1 adds a cluster-wide dedup toggle, and the first thing to get straight is what enabling it creates. It creates one dedup store for the whole cluster. Not one per host, not one per disk group. One store, a real backend object with its own UUID, holding two kinds of objects: chunk objects, which are the deduplicated data, and hash objects, which are the fingerprint index. If you go looking for dedup host by host, you will misunderstand what you are looking at before you start.

The store has a UUID, and the only place that UUID shows up is the command line. The Virtual Objects UI hides it, a documented 9.1 Known Issue. So the checks are CLI:

esxcli vsan dedup dedupstore get
esxcli vsan dedup dedupstore distribution get -c chunk
esxcli vsan dedup dedupstore distribution get -x hash

The first command shows the store: whether the service is enabled and paused, the store UUID, and the counts of chunk and hash objects. The distribution commands show how those objects spread across hosts.

The reading that proves the model is the shared UUID. On my cluster the day I enabled it, Oct 22, the store held 32 chunk objects and 32 hash objects. The distribution rows showed 10 chunk and 10 hash on the first host, 11 and 11 on each of the other two, and every single row carried the same store UUID. That sameness is the reading. If you see a different store UUID on one host, that is the anomaly. If you see the same one everywhere, the cluster agrees about its store, and you can stop wondering whether dedup is per-host.

Empty output is also a reading, and it is worth knowing before you need it. On a cluster with the feature off, both the store command and the distribution command answer with a single line: "Global dedup is not enabled on current host." That is not an error and not a failed command. It is the off state, stated plainly.

The resync commands are where I learned the most, because the numbers looked broken until I understood what they were saying:

esxcli vsan dedup dedupstore resync list
esxcli vsan dedup dedupstore resync summary get

I captured these during a reconfiguration where the cluster was resyncing more than 200 GB of VM objects. The dedup summary showed 64 total dedup objects, zero resyncing, zero bytes left to sync, and the resync list returned no output at all. My first instinct was that something was wrong with the dedup store. It was not. The dedup store does not resync with VM objects. The zeros and the empty list were the whole reading: the VM resync and the dedup store are separate tracks, and the dedup track was quiet.

That is the practical point for troubleshooting. When dedup looks wrong, check the store object itself: its UUID, whether it is enabled and unpaused, its distribution across hosts, and its resync state. Check whether the cluster agrees on one store before you chase host-level theories. And when the UI hides the one identifier you need, know the command that shows it.

This write-up is about the object model and the readings, not a savings claim. I enabled global dedup in the lab to learn how the store behaves, and these are the readings that taught me. Capacity numbers will come when there is something worth measuring; the shape of the thing comes first.