Choose a storage policy from the failures the service must survive, then prove the objects can actually satisfy it. A policy name such as Gold or Fast does not explain protection, capacity, placement or the temporary space needed to change it.
This guide uses a healthy standard single-site vSAN lab cluster and a disposable VM. It does not remove disks, inject hardware failures or reduce production redundancy. Exact supported layouts must be checked for the installed architecture and update.
1. Write a failure requirement before choosing RAID
For each workload, record tolerated host/device failures, acceptable performance during recovery, required maintenance availability and the independent backup requirement. Specify whether a whole rack or site is a failure domain. This article's single-site example does not establish site resilience.
Inventory whether the cluster uses Original Storage Architecture (OSA) or Express Storage Architecture (ESA). OSA disk groups and ESA storage pools have different mechanics; the same RAID label must not be assumed to imply identical implementation. Broadcom's vSAN terminology: https://knowledge.broadcom.com/external/article/326549/glossary-of-vsan-terms-and-acronyms.html explains the object/component and architecture distinctions.
Create a worksheet with workload, current policy, required tolerance, current compliance, consumed space, growth allowance and maintenance reserve. Reject a policy that cannot be placed on the cluster's actual fault domains even if its theoretical capacity ratio looks attractive.
2. Keep redundancy and reservation separate
Failures to Tolerate describes protection against a supported failure pattern. Object Space Reservation concerns reserved capacity. Thin allocation can reduce initially reserved space but does not reduce the application's eventual growth requirement.
Do not use FTT=0 to create apparent free capacity for an important workload. Broadcom documents that loss of a host/device containing an unprotected object can make its VM inaccessible. FTT=0 availability consequences: https://knowledge.broadcom.com/external/article/402909/vms-can-become-inaccessible-after-a-sing.html
For a simplified illustration, 1 TiB of payload mirrored in two data copies needs roughly 2 TiB for those copies before metadata, growth, snapshots and operational reserves. This is arithmetic, not a datastore sizing promise. Erasure-code ratios and supported stripe widths depend on architecture, release and host count; obtain them from the exact design rather than reusing an OSA formula for ESA.
3. Budget the transition, not just the final layout
Calculate existing data, expected growth, snapshots, repair/rebuild space and any temporary demand during policy conversion. Include capacity distribution across hosts and fault domains. Free bytes on a host that cannot hold the required component are not interchangeable with eligible capacity elsewhere.
For example, a new policy might reduce final steady-state use but still need temporary room while objects are rebuilt. If the cluster is already close to its operational limit, conversion is not an immediate guaranteed space-recovery technique.
Inspect current health and Resyncing Objects. Record any reduced-redundancy or non-compliant objects before the experiment. Do not add conversion work to an unhealthy cluster simply because the policy wizard permits submission.
4. Create a dedicated lab policy
Open Policies and Profiles > VM Storage Policies and create a new policy for the test. Use a name that states intent, such as LAB-FTT1-MIRROR-THIN, and a description recording architecture, workload and decision owner.
Enable vSAN rules, select the supported one-failure mirroring option and choose the reviewed reservation setting. Keep other settings at the approved baseline; do not change stripe width, IOPS limits and protection in one experiment. Review compatible storage before saving.
Broadcom documents the policy creation and application workflow: https://knowledge.broadcom.com/external/article/388937/reducing-vm-storage-consumption-on-vsan.html. Its stretched-cluster capacity example is not the sizing model for this standard-cluster guide. Use the workflow mechanics while preserving the reference design's scope.
Do not edit a shared production policy in place. That can change the intended state for many objects at once. A new lab policy provides a bounded target and preserves the original definition.
5. Apply the policy to known objects
Record the disposable VM's home object and each VMDK's current assignment. Review snapshots and other associated objects so that a disk-only change is not mistaken for complete VM coverage.
Use the VM's storage-policy editing workflow to assign the new policy to the intended lab objects. Read the scope before submission. Observe reconfiguration, resync and object compliance afterwards. The UI accepting an assignment means desired policy was set; it does not prove every component already matches it.
Retain before/after policy identifiers, object identities and compliance results in the private evidence packet. Publish only synthetic aliases. Do not distribute production component UUIDs or topology maps with the article.
6. Interpret health and recommendations carefully
If the datastore is incompatible, investigate supported rules, host count, architecture and fault-domain placement. If objects are temporarily non-compliant during conversion, inspect progress and resource demand. A stalled or failed conversion needs a cause, not repeated reassignment.
ESA may recommend an optimised default policy based on cluster characteristics. Broadcom documents an eight-node ESA case where the health recommendation favours RAID-6. That specific recommendation is not a universal mandate for every ESA cluster. ESA default-policy warning: https://knowledge.broadcom.com/external/article/459412/using-raid5-storage-policy-in-vsan-esa-c.html
Do not silence the health check or disable automatic policy management merely to make the dashboard green. Record whether the difference is intentional, supported and accepted by the workload owner. A recommendation, a configured policy and actual compliance are distinct facts.
7. Validate workload and maintenance behaviour
Run the same bounded application transaction before the change and after the cluster reaches the required steady state. Keep dataset, concurrency and cache treatment consistent. Record correct output, failure count, response distribution and storage latency.
Then plan a separate single-host maintenance rehearsal with the cluster owner. Review the selected data-migration option and its stated availability/protection consequences before entering maintenance. Do not use a reduced-movement option without accepting what remains exposed while the host is away.
Check the pre-maintenance capacity estimate, object accessibility and compliance during the exercise, then verify the cluster returns to its required healthy state after the host rejoins. This is planned maintenance acceptance. It does not prove survival of an abrupt host or rack failure.
Acceptance and reversal
The policy is accepted when the required objects are compliant, capacity/headroom remain adequate, application behaviour passes and the maintenance exercise meets its explicit protection requirement. Keep unsupported failure scenarios out of the acceptance claim.
Reassigning the previous policy may trigger another conversion and requires capacity too. Preserve the original definition and review reversal before the first change. Do not delete components, remove disk groups or weaken protection as a generic rollback.
Related topics: storage-latency diagnosis, controlled benchmarks and cluster maintenance.
Learning notes
- Policy assignment expresses intent; compliance reports whether objects meet it.
- Lower final space consumption does not eliminate transition-space requirements.
- Planned maintenance and unexpected failures require different acceptance evidence.
Sources and review status
See the source ledger, author self-check and series index. Independent review and lab validation remain pending.