DSM will happily show you a healthy mirrored pool. Whether that mirror protects anything depends entirely on where the virtual disks physically live — and the answer surprises most first-time builders.
This is the most misunderstood part of a virtual NAS. The pool is real, the mirror is real, and the protection can still be an illusion — because redundancy only counts across physical failures, and two files on one disk share one fate. This guide separates what the DSM layer guarantees from what the ESXi layer underneath quietly decides.
👆 The layering trap in one panel — DSM redundancy is only as real as the physical separation underneath it (layout recreated for illustration)
Inside DSM, a storage pool built from two disks with SHR or RAID 1 behaves exactly like the real appliance: every file written twice, one disk can fail, the pool carries on in a degraded state and nags you to replace the disk. Storage Manager's health pages, scrub schedules and repair buttons all work. If your goal is to learn the DSM storage workflow — creating pools, expanding them, rehearsing a degraded-pool repair — virtual disks teach it perfectly, because the software genuinely cannot tell the difference.
The catch is one layer down. If both virtual disks are VMDK files living on the same physical datastore disk, then the two mirrored copies sit on one piece of hardware. That disk's failure takes both copies in the same second, and DSM's healthy mirror becomes a healthy record of a total loss. The redundancy is real against a virtual disk failing; against the physical disk failing, it is theatre. With RDM disks the picture improves — two genuinely separate physical disks give the mirror something real to mirror across — but even then the host, its controller and its power supply remain shared single points of failure.
So set the rule by data value, not by what the pool claims:
Scrub schedules and SMART pages inside a VMDK-backed DSM deserve the same reading: they describe the virtual layer faithfully and the physical layer not at all.
Two practical notes. Thin vs thick: thin-provisioned VMDKs keep the datastore lean but let the lab promise more space than physically exists — the day two thin disks grow into each other, everything on the datastore stops. For a NAS lab, provision honestly or watch datastore free space like a fuel gauge. And remember the pool can never be bigger than the datastore beneath it, whatever numbers DSM displays: the virtual ceiling is set in ESXi, not in Storage Manager.
The video builds the storage pool step by step — watch how the pool and volume are created in this install.
▶️ Watch Full VideoDSM has done its job at the virtual layer: the second virtual disk failed and the mirror carried on. But if both virtual disks are files on one physical datastore disk, a failure of that physical disk still takes everything. Health inside DSM is not the whole story.
Yes. Pool creation, degraded states, repair and expansion behave the same as on hardware, so the workflow learning is genuine. Only the physical protection underneath differs.
Separate the copies physically — RDM disks on genuinely different drives helps, and a Hyper Backup copy outside the host helps more. No pool layout inside one VM can protect against the host itself failing.