VM does not reclaim null blocks

[GoobneIceChick]

Hello, I have a question regarding vSAN reclaim.

The environment is a CentOS8 VM running on vSAN RAID Level 5.

For disk 1, 40GB of space was allocated to install the OS, and 2TB of Disk 2 was configured as a DATA storage.

Disk 2 consists of a single partition of sdb1, and if you check with "df -h" command, 70GB of space is being used.

Based on vSAN RAID Level 5, it is calculated as 70G * 1.33, so it is expected to use about 93GB of space, but the disk uses about 262GB of VMDK capacity.

So I changed the VMDK's policy to RAID Level 1, and then reverted it back to the RAID Level 5 policy.

After doing this, the capacity of Disk 2 was reduced to 202GB.

With a question, I cloned the VM and performed the same operation, and the disk capacity of the cloned VM was 129GB.

Could you tell us an example of a situation similar to this one and a solution?

[lucasbernadsky]

Hi there! Hope you are having a nice day.

To get more information about the objects size and parity I suggest you open RVC console and run a vsan.vm_object_info (https://www.virten.net/2017/06/vsan-6-6-rvc-guide-part-3-object-management/#vsan-vm_object_info )

Also, take a look at this article, it's simply great: UNMAP/TRIM Space Reclamation on vSAN | vSAN Space Efficiency Technologies | VMware ​

Also take in consideration that if you have Dedup & compression enabled, the ratio may change depending on how the VM objects are distributed across diskgroups, so also check at that when comparing the two VMs

Regards!

[Lalegre]

I had this issue in the past and it was because of how the original VM was created that after the cloning the "proportional capacity" value in vSAN of the VM did not change to 0 (Thin) but was on 100 (Thick)

You can use the command Lucas mentioned and look in this RVC Command document: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsan/vmware-ruby-vsphere-...

There search for vsan.vm_object_info and make sure your VMs have proportionalCapcity=0. If they have for example 100 is expected that you face this issue and the resolution is to reapply a new Storage Policy for example RAID 1 when you have RAID 5 to completely reconstruct your objects and then go back to the RAID 1.

Please take into account that this change of policy is IO Intensive and also space consuming, you should have at least 25% or 30% space free (vSAN Slack Space) to make sure vSAN does not fill up during this task.

[GoobneIceChick]

Thanks for your answers.

However, they are already using All-Flash vSAN and Thin Provisioned RAID 5 policies.

I applied the RAID 1 policy to the VM and then reverted it back to the RAID 5 policy, which returned only 60GB of data.

In the RVC Console, about 200GB is being used for DISK 2, which is very different from the 71GB RAID 5 policy (93GB).

Here is their storage policy information. Please check.

Thank you.

Waiting for your reply

[Lalegre]

Did you sometime have that disk with a bigger size than 71Gb in the past?

I am asking this because the thin provisioning only occupies what you use but once you delete some files unless you run the TRIM/UNMAP operations, vSAN will still be identifying the old used size.

[GoobneIceChick]

Not as far as I know.

Even if you manually fstrim, it does not return the capacity above that level, and it is configured in CentOS so that vSAN can automatically unmap / trim.

In fact, I tested creating/deleting files to check that the vSAN Unmap/Trim function works properly in that VM, and I could see that the capacity increased and decreased.

So, as a last resort, I cloned that VM and checked the capacity, and as a result, I was able to see that the capacity was reduced to about 130 GB.

[Lalegre]

I am just comparing the screenshot that you took with my platform where i have exactly the same policy and i am just getting 4 copies of one object not 4 RAID0 of that object.

Which version of vSAN are you using? It seems that you are getting another placement of the objects instead of the ones you pointed on the policy. You should see 4 Components for that disk (3 data and 1 parity) so you get the 1x33 capacity as mentioned.

The command you ran was vsan.vm_object_info right? Because also on your output i am missing some parameters that i can see in mine.