vSAN -- vSphere Cluster Services (vCLS) -- Impact to vSAN Workflows
search cancel

vSAN -- vSphere Cluster Services (vCLS) -- Impact to vSAN Workflows

book

Article ID: 326879

calendar_today

Updated On:

Products

VMware vSAN

Issue/Introduction

Symptoms:
If vCLS VMs are placed on a vSAN datastore, then some of the vSAN Workflows could be impacted
as vCLS VMs cannot be powered off by Users.

Please note:
vCLS is a mandatory feature that is deployed on each vSphere Cluster (incl. vSAN) 
after vCenter is upgraded to vSphere 7.0 Update 1 or later or after a fresh deployment of vSphere 7.0 Update 1 or later. 
The ESXi Hosts can be of any older version which is compatible with vCenter server 7.0 Update 1.
( Reference: vSphere Cluster Services (vCLS) in vSphere 7.0 Update 1 and newer versions (80472) )


Environment

VMware vSAN 6.7.x
VMware vSAN 8.0.x
VMware vSAN 7.0.x

Resolution

Following some guidance on how to avoid/remove inaccessible vCLS VMs based on some vSAN Workflows: 

- vSAN Disable
If the Customer is disabling vSAN on a Cluster where vCLS VMs residing on its vSAN Datastore,
then these vCLS VMs will become inaccessible. 
Since these vCLS VMs are still showing up in the Inventory, the vCLS Services will try to power these on.
But the task will fail since the vCLS VMs have become inaccessible.

If Host(s) are being removed from the Cluster as part of disabling vSAN, 
then these vCLS VMs will be automatically cleaned up by the System,
as soon as the related Host(s) are placed in Maintenance Mode. 

If Host(s) are not being removed from the Cluster as part of disabling vSAN, 
then these vCLS VMs have to be migrated to a non-vSAN Datastore on the affected Cluster if available
otherwise, configure Retreat Mode to have the vCLS VMs removed from the cluster prior to disabling vSAN.


- vSAN Disk Group Removal
If several or all Disk Groups on a vSAN Cluster are being removed,
any vCLS VMs located on the affected vSAN Datastore will become inaccessible.
VMware recommends migrating these vCLS VMs to a non-vSAN Datastore on the affected Cluster if available
otherwise, configure Retreat Mode to have the vCLS VMs removed from the cluster prior to removing the Disk Groups.


- vSAN Cluster Shutdown
vCenter & vSAN 7.0 U3 & later:
Shutdown via Web Client - Shutdown Cluster Wizard 7.0
Shutdown via Web Client - Shutdown Cluster Wizard 8.0
Remark: vCLS VMs will be automatically powered off by the System.

vCenter on 7.0 Update 1 or later  &  vSAN 6.7 Update 3 or later:
Using a built-in tool to perform a simultaneous shutdown/reboot of all hosts in the vSAN Cluster (70650)

vCenter & vSAN on 6.x/7.x below versions 6.7U3 & 7.0U1 : 
Manually Shut Down and Restart the vSAN Cluster

- Failover in vSAN Stretched Clusters
The location of vCLS VMs cannot be configured using DRS rules. 
Following an Example:
Fault Domain "AZ1" is going offline.
As a result, all VM(s) located in Fault Domain "AZ1" are failed over to Fault Domain "AZ2".
This includes vCLS VMs.

When Fault Domain "AZ1" is back online,
all VMs except for the vCLS VMs will migrate back to Fault Domain "AZ1".
The vCLS VMs will stay in Fault Domain "AZ2",
even though there are DRS rules configured to instruct to move them back to Fault Domain "AZ1".
The workaround is to manually migrate vCLS VMs back to Fault Domain "AZ1".

Further information in regards to DRS and vCLS VMs: 
vSphere Cluster Services


- Unmounting HCI Mesh
Only for running vSphere & vSAN 7 Update 1 & later.

Before unmounting a HCI Mesh connected Remote Datastore, ensure that no VMs are on it.
This includes any vCLS VMs.
Clean the affected vCLS VMs up by configuring Retreat Mode, before unmounting a HCI Mesh connected Remote Datastore.

Further Information:
Sharing Remote Datastores with HCI Mesh
HCI Mesh - Unmount Remote Datastore

- Alarms in the vSAN Skyline Health Check
vSAN Skyline Health might show Alarms in relation to Workflows affecting vCLS VMs.
In order to avoid these Alarms, it is recommended to follow the Instructions above
and/or to clean the affected vCLS VMs up by configuring Retreat Mode.