Enabling the Deduplication and Compression fails with error : "General vSAN error. Resource check failed.."

Products

VMware vSAN

Issue/Introduction

Symptoms:

When attempting to enable cluster-wide services (such as Deduplication and Compression or Data-At-Rest Encryption) on a VMware vSAN cluster, the configuration task fails.
The vSAN cluster configuration consistency check triggers an alert, and the following error is reported in the tasks/UI:

"General vSAN error. Resource check failed - Retry operation after adding or freeing <VERIFY_CAPACITY> GB of capacity on each node in the cluster. Resource check failed - Cluster doesn't have enough resources. Sample failed object: {failedObject}."

Environment

VMware vSAN OSA 8.x

VMware vSAN OSA 9.x

Cause

Enabling deduplication and compression requires a format change for disk groups. To accomplish this change, vSAN evacuates data from the disk group, removes the disk group, and recreates it with a new format that supports deduplication and compression.

In certain environments, your vSAN cluster might not have enough resources for the disk group to be fully evacuated. Examples for such deployments include a three-node cluster with no resources to evacuate the replica or witness while maintaining full protection. Or a four-node cluster with RAID-5 objects already deployed. In the latter case, you have no place to move part of the RAID-5 stripe, since RAID-5 objects require a minimum of four nodes.

Resolution

Option 1: Allow Reduced Redundancy Selecting "Allow Reduced Redundancy" permits vSAN to temporarily drop the compliance level of virtual machine objects during the format change. This bypasses the strict free capacity constraints on the storage-contributing nodes. Full policy compliance is automatically restored after completion.

Navigate to the vSAN cluster in the vSphere Client.
Go to Configure > vSAN > Services.
Edit the Deduplication and Compression settings.
Select the check box for Allow Reduced Redundancy.
Apply the changes.

Note: This option keeps the VMs running, but the VMs might be unable to tolerate the full level of failures defined in the VM storage policy. As a result, temporarily during the format change for deduplication and compression, your virtual machines might be at risk of experiencing data loss. vSAN restores full compliance and redundancy after the format conversion is completed.

Option 2: Add Storage Capacity If temporarily reducing redundancy violates organizational requirements, you must satisfy the pre-check constraints by expanding the cluster's storage footprint to provide the requested slack space.

Scale Up: Add new supported storage devices to the existing storage-contributing ESXi hosts in the cluster.
Scale Out: Add new ESXi hosts equipped with supported storage devices to the cluster. Note: Adding additional compute-only hosts will not satisfy the vSAN data evacuation requirements.
Once the new capacity is successfully claimed by the vSAN datastore, retry the deduplication and compression enablement task without selecting "Allow reduced redundancy".

Additional Information

Reference article: Reduce VM Redundancy for vSAN Cluster

Evacuation Capacity Constraints by Topology:

2-Node Cluster (RAID-1 FTT=1): Evacuating a host in a 2-node cluster strictly requires the "Allow Reduced Redundancy" option to bypass the lack of a third data node. However, the single remaining active node must still possess enough absolute free physical capacity to hold all evacuated data components without exceeding disk utilization limits.
Standard Cluster (RAID-6 FTT=2): Maintaining strict FTT=2 during a full host evacuation requires a minimum of 7 storage-contributing hosts. Even when bypassing fault domain constraints using "Allow Reduced Redundancy", the remaining active nodes across the cluster must still possess sufficient contiguous slack space to absorb the 1.5x parity overhead components.