Error: General vSAN error. vSAN resource check has failed on host when entering Maintenance Mode with Full Data Migration
search cancel

Error: General vSAN error. vSAN resource check has failed on host when entering Maintenance Mode with Full Data Migration

book

Article ID: 326857

calendar_today

Updated On:

Products

VMware vSAN

Issue/Introduction

Symptoms:

  •  Host fails to enter maintenance mode with "Full Data Migration" selected.
  • Error: General vSAN error. vSAN resource check has failed on host. Go to vSAN data migration pre-check page for more details.

  • Data migration precheck fails with: 1 more standalone host is required. Some objects will become inaccessible or non-compliant with their storage polic


          

     vSAN cluster requirements -

      

The task using Full Data Evacuation will also hang and/or fail when there is insufficient space to migrate all of the data to other hosts.

Environment

VMware vSphere vSAN 8.x


Cause

  • vSAN requires a certain number of hosts to be active with disk groups contributing capacity and resources in vSAN in order to provide fault tolerance. If the requirements cannot be met, vSAN will fail the pre-check it performs when placing a host into maintenance mode. 
     
     
  • Even if the Storage policy has changed on the VMs to match the fault domains available after placing a host in maintenance mode with "Full Data Migration", there may be unknown, unassociated and inaccessible vSAN objects whose storage policy remains same, and this causes the maintenance mode task to fail.
     


    See the below documentation for further information:

  • This error can also be seen if there is any hard disk of any VM which is configured with the improper storage policy. If after putting the host in maintenance mode, the object placement requirements are not fulfilled, this error is expected.
     


    When entering Maintenance Mode a "What-if" scenario will be run. If the result is, that after entering Maintenance Mode only not enough Fault Domains will be available the Full Data migration will fail. 

    The clomd.log will provide the related error message:
    LOM_CheckClusterResourcesForPolicy: Not enough Upper FD's available. Available: 3, needed: 4
    LOM_CheckClusterResourcesForPolicy: Not enough Upper FD's available. Available: 4, needed: 5
     
    For space related inability to enter with Full Data Evacuation the "What-if" will also indicate the task will fail.

Resolution

1. Fault Domain Related Failures

  • Full Data Migration: If full data migration is required, you must add additional hosts to the vSAN cluster before proceeding based on the configurations below

              RAID 5: Requires the addition of a 5th host.

              RAID 1: Requires the addition of a 4th host.

              RAID 6: Requires the addition of a 7th host.

  • Policy Adjustment: Alternatively, modify the Storage Policy to FTT=1 and FTM=RAID1. Ensure any hard disks configured with an improper storage policy are corrected to fix the issue.

    Note: When changing policies from RAID 5 or RAID 6 to RAID 1, or from RAID 6 to RAID 5, vSAN creates new components first and deletes the old ones only after the rebuild is complete. Verify that there is sufficient free space in the cluster before proceeding.

  2. Unknown and Unassociated Objects:

  • Limitation: Changing the storage policy for unknown and unassociated objects is not supported via the vSphere Client.

  • Resolution: If you encounter this scenario, open a support request with Broadcom Technical Support for assistance Broadcom Technical Support

3. Inaccessible vSAN Objects

  • Resolution: Attempt to bring the objects back to a healthy state. If the objects are confirmed stale, validate and delete the inaccessible virtual objects from the vSAN cluster.

  • Workaround: Place the affected host into Maintenance Mode using the Ensure Accessibility option.

  • Warning: All data utilizing RAID 5 or RAID 6 Storage Policies will operate in a reduced redundancy state until the host exits Maintenance Mode and the data resyncs back to compliance

4. Insufficient Space Related Failures

  • Resolution: Add capacity to the cluster to allow data to rebuild successfully. This can be achieved by adding new hosts to the cluster or adding capacity disks to existing hosts.

  • Workaround: Place the affected host into Maintenance Mode using the Ensure Accessibility option.

  • Warning: All data with components on the host in Maintenance Mode will operate in a reduced redundancy state until the host exits Maintenance Mode and the data resyncs back to compliance.

5. vSwap Related Objects

  • Recommended Resolution: Power off and then power on the affected virtual machine.

  • Alternative for Production Workloads: If powering off the virtual machine is not possible, you can modify the policy on the swap objects using the objtool command-line utility.

    Run the appropriate command below based on your desired RAID level:

               Raid 0
        /usr/lib/vmware/osfs/bin/objtool setPolicy -u < UUID > -p "((\"proportionalCapacity\" i0)(\"hostFailuresToTolerate\" i0))"

        Raid 1 
       /usr/lib/vmware/osfs/bin/objtool setPolicy -u < UUID > -p "((\"proportionalCapacity\" i0)(\"hostFailuresToTolerate\" i1))" 

       
Raid 5 
    /usr/lib/vmware/osfs/bin/objtool setPolicy -u < UUID > -p "((\"stripeWidth\" i1) (\"cacheReservation\" i0) (\"proportionalCapacity\" i0) (\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i0)  (\"replicaPreference\" \"Capacity\")  (\"iopsLimit\" i0)                  (\"checksumDisabled\" i0))"
 
               RAID 6
/usr/lib/vmware/osfs/bin/objtool setPolicy -u < UUID > -p "((\"stripeWidth\" i1) (\"cacheReservation\" i0) (\"proportionalCapacity\" i0) (\"hostFailuresToTolerate\" i2) (\"forceProvisioning\" i0)  (\"replicaPreference\" \"Capacity\") (\"iopsLimit\" i0) (\"checksumDisabled\" i0))" 

Additional Information