vSAN Storage Policies in VCF: Placement, Failures, and Capacity
A practical guide to vSAN storage policies in VMware Cloud Foundation: what each setting means, how objects land on hosts, and how much capacity common policies consume.
vSAN storage policies are one of those features that sound simple until you are staring at an object placement screen wondering why a 100 GB disk is using 200 GB, 150 GB, or sometimes more. In VMware Cloud Foundation (VCF), the idea is still simple: a policy is the promise vSAN tries to keep for each VM object.
That promise answers four practical questions:
- How many failures should this VM survive?
- Should protection happen inside one site, across two sites, or across two hosts?
- Should vSAN use full mirrors or parity?
- Do we care more about performance, space efficiency, or locality?
Broadcom’s VCF 9.1 documentation says vSAN VMs must have at least one storage policy, and that VCF 9.1 ESA can use an Auto-RAID policy that automatically chooses site disaster tolerance and failures to tolerate. That is a good default. This guide is for the moment when you want to understand or override what the policy is doing.
The mental model: objects, components, and witnesses
A VM is not one big file to vSAN. The VM home namespace, every VMDK, and supporting objects are stored as vSAN objects. A large object is broken into components. A policy tells vSAN how many copies or parity pieces those components need, and where those pieces are allowed to live.
The small but important rule: vSAN separates components across hosts or fault domains so one failure does not take every copy with it.
For RAID-1 mirroring, you normally see data components plus a witness. The witness does not contain the VM’s data. It is metadata used for quorum, which helps vSAN decide which side of a split or failure still owns the object.
The policy options that matter
Here are the policy settings you will meet most often in VCF and vSAN.
| Setting | Plain-English meaning | Beginner recommendation |
|---|---|---|
| Site disaster tolerance (SDT) | Decides whether the policy is for a standard cluster, a 2-node cluster, or a stretched cluster. | Leave as standard unless the cluster is actually 2-node or stretched. |
| Failures to tolerate (FTT) | How many host, disk, or site-local failures an object should survive. | FTT=1 is the normal starting point for production workloads. |
| RAID type / failure tolerance method | RAID-1 uses full mirrors. RAID-5/6 uses data plus parity for better capacity efficiency. | Use RAID-1 for small clusters or latency-sensitive writes; use RAID-5/6 when capacity matters and the cluster shape supports it. |
| Number of disk stripes per object | Minimum number of capacity devices each replica is striped across. | Keep the default of 1 unless you have measured a specific performance problem. |
| Object space reservation | Thin or thick provisioning for the VMDK object. | Thin by default. Thick only when a workload truly needs guaranteed reserved space. |
| IOPS limit for object | Throttles a VMDK if it exceeds the configured IOPS limit. | Usually leave unlimited. Use for noisy-neighbor control. |
| Checksum | End-to-end data integrity checking. | Leave enabled. In ESA, object checksum is always on. |
| Force provisioning | Allows provisioning even when the policy cannot currently be satisfied. | Avoid in normal production. Useful mainly for bootstrap or outage recovery scenarios. |
Broadcom’s policy documentation is very direct on two of these: the default stripe value is 1, and force provisioning is not the normal production path when policy requirements cannot be met.
Capacity overhead quick table
The table below is the cleanest way to explain where the space goes.
| Policy shape | Typical layout | 100 GB logical data consumes | Minimum shape |
|---|---|---|---|
| FTT=0 | One copy | 100 GB | 1 host, no redundancy |
| FTT=1 RAID-1 | 2 mirrors + witness | 200 GB | 3 hosts for standard RAID-1 quorum |
| FTT=2 RAID-1 | 3 mirrors + witnesses | 300 GB | 5 hosts |
| OSA FTT=1 RAID-5 | 3 data + 1 parity | About 133 GB | 4 hosts or fault domains |
| ESA FTT=1 RAID-5 2+1 | 2 data + 1 parity | 150 GB | 3 hosts or fault domains |
| ESA FTT=1 RAID-5 4+1 | 4 data + 1 parity | 125 GB | 6 hosts or fault domains |
| FTT=2 RAID-6 4+2 | 4 data + 2 parity | 150 GB | 6 hosts or fault domains |
Two important details from Broadcom’s VCF 9.1 docs:
- RAID-5/6 can provide the same protection level as RAID-1 while using less capacity.
- In ESA, Auto-RAID changes the RAID-5 layout depending on cluster size: 2+1 for 3-5 hosts, and 4+1 for 6 or more hosts.
So if someone says “RAID-5 is always 1.33x”, pause. That is true for classic 3+1 erasure coding, but VCF 9.1 ESA commonly uses 2+1 at smaller scale, which is 1.5x.
Example 1: 2-node vSAN cluster
A 2-node vSAN cluster is common for edge sites and smaller rooms. You have two data hosts and a witness appliance at another location. The witness does not run the VM data. It helps with quorum.
Edge site Witness site
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Host A │ │ Host B │ │ Witness │
│ data A │ │ data A │ │ metadata │
└──────────┘ └──────────┘ └──────────┘
Policy: 2-node host mirroring
VM data size: 100 GB
vSAN datastore usage: 200 GBWhat this means in real life:
- Lose Host A: the VM can keep running from Host B.
- Lose the witness only: the data is still present on both hosts, but you should repair the witness path.
- Lose Host A and the witness at the same time: you are in dangerous territory because quorum is affected.
Do not think of a 2-node policy as “half a stretched cluster.” It has a similar witness idea, but the design goal is usually local host failure protection for a small site, not full active-active site placement.
Example 2: 3-node standard cluster
This is the classic lab or small production cluster. The usual beginner-safe policy is FTT=1 with RAID-1 mirroring.
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Host 1 │ │ Host 2 │ │ Host 3 │
│ data A │ │ data A │ │ witness │
└──────────┘ └──────────┘ └──────────┘
Policy: standard cluster, FTT=1, RAID-1
Placement: two full mirrors + one witness
VM data size: 100 GB
vSAN datastore usage: 200 GBWith only three hosts, your choices are intentionally limited:
- RAID-1 FTT=1 works well and is easy to reason about.
- RAID-5 in ESA can be possible as 2+1, but it is still more parity-oriented and less forgiving during maintenance windows.
- RAID-6 is not a fit because it needs six hosts or fault domains.
For low-experience operators, I would rather see a boring 3-node FTT=1 RAID-1 policy than an over-optimized policy nobody understands during a host evacuation.
Example 3: 6-node standard cluster
Six hosts is where capacity-efficient policies become more interesting. In ESA, the Auto-RAID behavior can choose RAID-5 4+1 for FTT=1, which lowers overhead to 1.25x. For FTT=2, RAID-6 4+2 protects against two failures at 1.5x.
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Host 1 │ │ Host 2 │ │ Host 3 │ │ Host 4 │ │ Host 5 │ │ Host 6 │
│ data 1 │ │ data 2 │ │ data 3 │ │ data 4 │ │ parity 1 │ │ parity 2 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
Policy: standard cluster, FTT=2, RAID-6 4+2
Placement: four data components + two parity components
VM data size: 100 GB
vSAN datastore usage: 150 GBThis is the first example where the capacity saving is dramatic:
| 100 GB VMDK policy | Approximate consumed capacity | What you are buying |
|---|---|---|
| FTT=1 RAID-1 | 200 GB | One failure tolerated, simple mirrors |
| FTT=1 RAID-5 4+1 | 125 GB | One failure tolerated, better efficiency |
| FTT=2 RAID-1 | 300 GB | Two failures tolerated, highest mirror cost |
| FTT=2 RAID-6 4+2 | 150 GB | Two failures tolerated, much better efficiency |
The tradeoff is write behavior. RAID-1 is simple: write the data to both mirrors. Parity layouts need parity calculation and more coordination. Modern ESA handles this far better than older OSA designs, but the design habit remains useful: choose RAID-1 for the most latency-sensitive write-heavy workloads, and choose RAID-5/6 when space efficiency matters and the cluster is sized for it.
Example 4: stretched cluster
A stretched cluster adds a site-level promise. The policy can say “keep the object available if one site fails.” That is separate from the local FTT inside each site.
Preferred site Secondary site Witness site
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Host A1 │ │ Host A2 │ │ Host B1 │ │ Host B2 │ │ Witness │
│ data A │ │ data A │ │ data A │ │ data A │ │ metadata │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
Policy: site mirroring + local FTT=1 RAID-1
Placement: two mirrors in each site + witness
VM data size: 100 GB
vSAN datastore usage: 400 GBThis is where many people get surprised. “FTT=1” might mean different things depending on which layer you are looking at:
- Site disaster tolerance protects against a site failure.
- Local FTT protects against host or device failures inside a site.
If you mirror across two sites and also mirror inside each site, you can end up with four full data copies. That may be exactly right for a critical management workload. It is probably not right for every ISO library, test VM, or backup landing disk.
Broadcom’s VCF documentation also describes site-affinity choices for stretched clusters: keep data on the preferred site, keep data on the secondary site, or mirror between sites. Affinity policies are useful when a workload should live mostly in one site, but they are not the same as site failure tolerance.
Choosing policies in real environments
Start with the failure you are trying to survive, not with the RAID level.
For a 2-node edge site, use the 2-node host mirroring policy for production VMs. It is simple, readable, and aligns with the physical design. Keep enough free capacity on both hosts for repair and maintenance.
For a 3-node cluster, FTT=1 RAID-1 is the easiest operational baseline. You can explore ESA Auto-RAID behavior, but be careful about putting every workload on the most space-efficient policy just because the UI allows it.
For a 6-node cluster, create at least two policies:
gold-raid1-ftt1for write-heavy or latency-sensitive VMs.silver-raid5-ftt1orsilver-raid6-ftt2for capacity-efficient general workloads.
For a stretched VCF management or VI workload domain, be explicit. Name policies by the promise they make, for example:
stretched-site-mirror-local-ftt1preferred-site-no-sdtsecondary-site-no-sdt
Names matter because nobody wants to decode a policy during an outage.
The common mistakes
The first mistake is treating “compliant” as “best.” Compliance only means vSAN can currently satisfy the policy. It does not mean the policy is sensible for the workload.
The second mistake is ignoring maintenance mode. A policy might survive one host failure on paper, but if the cluster is already short on free space, vSAN may not be able to rebuild or evacuate cleanly.
The third mistake is using force provisioning to make warnings disappear. Force provisioning can be useful in a bootstrap or emergency scenario, but in normal production it is vSAN telling you the cluster cannot keep the promise you asked for.
A practical decision flow
Ask these in order:
- Is this a standard, 2-node, or stretched cluster?
- Does the VM need to survive a site failure, or only a host/device failure?
- How many local failures must it tolerate?
- Is write latency more important than usable capacity?
- Does the cluster have enough hosts or fault domains for the policy?
- After applying it, does object placement look like the promise you intended?
If you can answer those six questions, vSAN policy design becomes much less mysterious. You are no longer picking random dropdown values. You are describing failure behavior, capacity cost, and placement.