vCLS and Virtual Volumes

vCLS

vCLS or vSphere Cluster Services was introduced in vSphere 7.0 U1 as a way to manage vSphere DRS and vSphere HA with the intended goal, as far as I understand it, to allow these services to eventually run without the vCenter (not yet). vCLS is represented by eponymous VMs, with 1-3 per vSphere cluster.

Generally, VMware wants you to regard these VMs as system owned and therefore they should not be manipulated in any way. While it is possible to disable vCLS through an advanced setting (see Duncan’s demo), DRS and HA don’t work without them so the point is moot. I should mention, however, that for anyone who has had the displeasure of “lost” or disconnected vCLS VMs, using the advanced setting is one of the only ways to clean things up. The normal method for removing dead VMs, “remove from inventory”, does not work for vCLS VMs. For all the gory details, and restrictions/caveats/whatever see VMware’s KB.

vCLS on vVol datastores

I’m no fan of vCLS if that opening salvo wasn’t convincing enough. They just came out in vSphere 7 but constantly cause me grief. In the initial release, the user had no control where the vCLS VMs lived. VMware placed them on whatever datastores it wanted, which could include datastores on arrays which were short-lived, or even vVol datastores (there are datastores it cannot use like those involved in SRM). The reason vVol datastores concern me is these vCLS VMs seem to come and go quite a bit. They aren’t large at all – 2 GB vmdk, 128 MB RAM – but unlike a VMFS datastore where new VMs are just files, on a vVol datastore each time a new vCLS VM is created it means three new devices on the array (swap, config, data). To create new vVol VMs take array resources, to say nothing of the resources needed to tear down the old ones, assuming they can be and aren’t lost. And when they are lost, they lead to what are known as “orphan vVols”, vVols that are no longer associated with any object (only support can remove them). Furthermore, if VMware cannot create a vCLS VM, it keeps trying and trying, sending more and more requests to the VASA Provider which invariably will lead to more orphan vVols and slow things down.

Datastore placement

The lack of control of where to place vCLS was a pain point for customers and through their insistence, VMware introduced datastore placement in Sphere 7 U3. This works just like it does for VMFS heartbeating, where you can assign datastores to vCLS and VMware must use them. Since you can have 1-3 VMs, best to use at least 3 datastores like so:

Note that the SOLUTION BLOCKED tab shows datastores vCLS has ruled out, like those involved in SRM.

In my environment, datastore placement prevents the use of vVol datastores, as well as those datastores on my testing arrays. Now, if your environment is 100% vVol, VMware does allow you to use the local datastores (non-shared) if you want. Obviously it can’t use vMotion on the VM, but as I said VMware creates and destroys regularly so it’s not an issue. I do recommend using those local ones over vVol datastores.

---

So best recommendation is to assign non-vVol datastores for vCLS if you are at a minimum of vSphere 7 U3.

Advertisement