You are currently viewing How to Prevent vCLS VMs from Landing on Temporary NFS Datastores (and Why You Should)

How to Prevent vCLS VMs from Landing on Temporary NFS Datastores (and Why You Should)

vCenter 7.x introduced the concept of vSphere Cluster Services (vCLS) VMs. These small, lightweight VMs ensure critical cluster services like vSphere DRS and vSphere HA continue to run in the event vCenter Server itself becomes unavailable. By design, vCLS VMs automatically get deployed within every vSphere cluster. However, this automation can sometimes lead to undesirable placements—such as on a temporary NFS datastore that Veeam might attach for vPower NFS powered restores.

In this blog post, we’ll discuss why you generally don’t want vCLS VMs on temporary backup datastores and how to configure your environment so vCLS VMs avoid them altogether.


Why You Don’t Want vCLS VMs on Temporary Backup Datastores

  1. Frequent Unmounts and Re-mounts
    Backup solutions like Veeam often present temporary NFS datastores for short windows of time—just long enough to restore data. Since these datastores can appear and disappear frequently, placing vCLS VMs on such storage can lead to operational headaches or even cluster service interruptions.
  2. Potential for Snapshot or Lock Conflicts
    Veeam (or other backup solutions) might create or manage snapshots on these datastores, which can cause conflicts if the datastore is also hosting active VMs like vCLS. This could lead to vCLS VMs becoming unavailable or stuck.
  3. Performance and Reliability Concerns
    Temporary NFS volumes may not be tuned or intended for running production or system-level VMs, which could introduce latency or reliability issues. Placing the critical cluster service VMs on them could create instability in vSphere HA/DRS operations if the datastore experiences unexpected slowdowns or disconnections.
  4. Administrative Overhead
    If a vCLS VM lands on the backup datastore, you might see repeated alerts, or you’ll have to perform manual migrations whenever Veeam unmounts the datastore. This is simply added administrative overhead you don’t need.

How to Control or Prevent vCLS VM Placement

In vSphere, VMware introduced advanced settings that let you specify which datastores vCLS VMs can (or cannot) use. You can find these settings under:

  1. Cluster > Configure > vSphere Cluster Services > Datastores.
  2. Look for “vCLS Allowed“.
  3. Click “Add“.
  4. Select your production datastores that the vCLS VMs should live on.
  5. Click “Add” again to save this selection.

If you have vCLS VMs stuck on an inaccessible datastore, this should also re-deploy and resolve the issue so that the inaccessible datastore can be removed from inventory.

I stumbled across this issue at one point in time when I was still using VMware in my home lab, but unfortunately I have since moved to Proxmox and did not take screenshots of how to do this first. In order to get a better step-by-step guide as well as an alternative method, read this great writeup by fellow Veeam Vanguard Luciano Patrão.


Conclusion

By default, vCLS VMs are designed to ensure the health of your cluster’s DRS and HA services, and they’ll automatically place themselves on any valid datastore in the cluster. That’s usually convenient, but not if you have a Veeam-managed (or similar) temporary NFS datastore that comes and goes. In that scenario, vCLS VMs can become a nuisance or a source of confusion when they attempt to deploy onto storage that’s not meant for continuous operations.

Setting allowed datastores for vCLS can help you keep vCLS VMs where they belong—on reliable, always-available datastores—while leaving the backup storage free for the jobs it was intended to support.

By keeping vCLS VMs off ephemeral or backup-focused datastores, you’ll minimize the risk of cluster instability, reduce unwanted alerts, and maintain a simpler, more predictable backup workflow.

Jonah May

Hey there! I’m Jonah May, a Product Architect and Product Engineering Manager at CyberFortress, a Platinum VCSP dedicated to keeping data safe and recoverable. When I’m not working on backup strategies and automation, you’ll find me deeply involved in the Veeam community—as a Veeam Vanguard, Veeam Certified Architect, VCSP Technical Ambassador, and co-founder of the Veeam Community Hackathon. I also help lead the Texas and Automation Desk Veeam User Groups, where we nerd out over all things backup, automation, and infrastructure.Beyond tech, I’m a Scout leader, having earned my Eagle Scout back in the day. I love sharing knowledge, solving problems, and making technology work smarter, not harder. If you’re into Veeam, automation, or home labs, let’s connect!

Leave a Reply