Can you check whether you have a snapshot on that vmdk?
Storage Policies only apply these to the last Object in the chain which would be the last snapshot if present, thus it is imperative that you consolidate these before attempting to change Storage Policies:
You should try looking at this with more detail and should also consider ruling out other possible causes of any incorrect information if it is indeed incorrect (e.g. using an incompatible vCenter version to manage the hosts, configuration of the vmdks is non-standard e.g. shared disks, vmdk deployed/restored through non-standard means, data is in an impaired state etc.).
With regard to what details you should check, start with:
- Whether the Objects in question are anything other than 'compliant' with their applied Storage Policy.
- What the 'vSAN Default Storage Policy' rules are - these can be changed e.g. my 'vSAN Default Storage Policy' isn't necessarily the same as your 'vSAN Default Storage Policy'
- What the layout and usage of the VM, this can be easily checked via a number of means, simplest (with adequate detail) being to get this info from RVC with vsan.vm_object_into against the VM or vsan.object_info against the vmdk in question (or 'esxcli vsan debug object list' run on a host).
Would it be a different behavior while these VMDK files is thin or thick provisioned ?
Just asking a a new vSAN learner, Thanks in Advance for your help
Yes it is compliant
This is a new VM (Deployed towards the end of last year) so no restores, detach/re-attach, or any other actions have been performed on this VM, and it is thin provisioned.
My Default policy is RAID1, which is why I want to move it to RAID 6, but I'm not sure why that would have any impact on the incorrect details I am seeing?
I've pulled the vsan.vm_object_info details, but I'm not sure what I am looking for here
Unfortunately that is not the full output of the command I suggested - this should return the component placement and size layout for all components of all Objects that make up the vmdk Objects associated with that VM.
I was suggesting to check this output versus what you are seeing in the UI so that we can determine what the actual structure and logical + physical usage of the data components are (which is generated from querying CMMDS and thus should be the source of truth regarding the size of things here).