vSphere 8 – VM configuration object stored on a VVOL datastore

vSphere 8 and VM configuration stored running on a datastore type VVOL has changed.
Let’s call it the 255GB config object pitfall.

„Starting at vSphere 8.0U1, the config vVols are now created with thin provisioned size of 255GB and formatted with VMFS-6.“

Source:
https://core.vmware.com/resource/whats-new-vsphere-8-core-storage#sec32279-sub1

Now, let’s figure out what this change means to a thin provisioned storage system e.g. a SAN.

We start with an easy exercise of deploying 10 VMs from a template. The Windows GuestOS drive is about 90GB and the vRAM is set to 4GB. In this case the vRAM is not reserved. From a thin provisioned SAN perspective, this configuration will allocate approximately 20GB. During the lifetime of such a VM it will allocate more capacity but we still don’t expect more than 100GB in total.
Thinking of some buffer, we could calculate with 1,2 TB for these 10 VMs in our example.

 

 

In my next step I will deploy the same template 10 times, but I associate a storage policy which is compliant to my datastore type VVOL.

The next two pictures below give us an impression on how it looks like if just one VVOL based VM was deployed. Stay tuned and monitor the over-subscription counter.

 

Let’s create few more VMs and monitor the SAN regarding the used capacity and the subscribed capacity.

 

After creating some VMs, we see the VVOL objects created on the SAN.
One object I’ve highlighted is the config object (255 GB). In former versions this object was just 4 GB large.

 

 

In conclusion, the SAN will report an huge over-subscription while there is still plenty of free space. That could scare the admin. The SAN admin always tries to monitor over-subscription and the root cause.

Be aware of the cause gives confidence and the control over this important module of a data center.

 

 

 

A valid question: how should I get back the control over my SAN and how should I adapt my monitoring to not get flooded by false alerts.

One answer could be: revert to the prior behavior. The VMware KB 90791 describes the procedure.
https://kb.vmware.com/s/article/90791

Reverting the behavior could help on storage challenges but other solved challenges will be back. On the long run the storage monitoring needs an update to filter out these large objects from the basic calculation of the relevant over-subscription counter. UNMAP operation on such an object was introduced in the latest vSphere 8.0.2 version.

To demonstrate all these dependencies I’ve installed the DataCore SANsymphony SAN on a vSphere 8.0.2. A high available VASA provider is included.
In a small training environment one node suffice. Nice experience and it runs in a homelab. For the HCI architecture and if you have more hardware to play around with, they have a highly automated deployment tool as well. Cool stuff to explore all the comprehensive VMware products without the need to buy a certified hardware storage for all the disciplines like SRM or SPBM etc.