Hosts fail to enter maintenance mode with full data evacuation
search cancel

Hosts fail to enter maintenance mode with full data evacuation

book

Article ID: 450527

calendar_today

Updated On:

Products

VMware vSAN

Issue/Introduction

Symptoms

  • The Maintenance Mode Precheck fails with the following error: Resource check failed - Internal failure happened during the resource check. Please check clomd.log on host #### for more details.

  • The vCenter Server Recent Tasks pane may show the "Enter Maintenance Mode" task stuck .

  • No objects are inaccessible and there is adequate capacity for evacuation

Environment

  • VMware ESXi 8.x

  • Cluster recently converted from a Stretched Cluster  to a Standard Cluster

Cause

  • Existing vSAN objects remain assigned to legacy Stretched Cluster Storage Policies that require dual-tier failure tolerance (Secondary Failures to Tolerate). Since the cluster has been converted to a Standard topology, the Cluster Level Object Manager Daemon (clomd) cannot resolve placement decisions for stretched rules. Consequently, clomd encounters internal failures during data migration resource calculations because the site topologies referenced in the old policies no longer exist.
  • Review /var/run/log/clomd.log on the affected host for the following entry: 

CLOMValidateAndUpdateTargetPolicy: subFailuresToTolerate is not supported in non-stretch!

  • Verify the object policy using the following command: localcli vsan debug object list

  • Check for the subFailuresToTolerate attribute in the output

Policy:
  stripeWidth: 1
  hostFailuresToTolerate: 1
  subFailuresToTolerate: 1 <-- Unsupported in Standard Cluster
  spbmProfileName: ####

Resolution

Method 1: SPBM Policy Update (Preferred)

Identify the storage policy applied to the affected objects.
Modify the storage policy in the vSphere Client to remove the subFailuresToTolerate rule.
Ensure the policy is compliant for a standard vSAN cluster (e.g., RAID-1 or RAID-5/6 without secondary site rules).
Reassign the affected objects to the updated policy and wait for resynchronization to complete.

Method 2: Manual Policy Correction via CLI

If the precheck continues to fail after updating the SPBM policy, manually strip the unsupported attributes from the specific object(s) using objtool on the ESXi host:

Identify the Object UUID from the clomd.log or localcli vsan debug object list command.
Apply a standard single-site policy (e.g., FTT=1) to the object /usr/lib/vmware/osfs/bin/objtool setPolicy -u <OBJECT_UUID> -p '(("hostFailuresToTolerate" i1))'
Retry the Maintenance Mode Precheck.

If the issue persists, contact contact-broadcom-support for further assistance.

To ensure your environment is running the latest fixes, verify your build version at Broadcom Software Downloads.