That is because you are using VSAN and Storage policy with FTT1 (RAID 1, mirrored volume). Since the vmdk is mirrored the actual usage of the disk shows twice than actual size which is expected.
I thought about it too, and yes, it's logical. But this situation happens only with this VM. Is it possible that this policy applies only to this VM?
I checked the storage policies of this vm and it has the same ones as the others
Other VMs doesnt show double size ? Can you compare this vm with other vm at settings level , there should be some difference .. can you please post the screenshots of storage policy and the VM which was tagged to it not occupying double size. Lets compare and see..
A hearty welcome to Communities.
It's (likely) either:
a) proportionalCapacity=100 on the vmdk Object and regardless of the storage policy having OSR=0 it is reserving the space, this is easily identified using RVC:
> vsan.vm_object_info <pathToVm>
e.g. from root directory (and assuming it is not in a DRS Resource Pool):
> vsan.vm_object_info ./localhost/DataCenterName/computers/ClusterName/resourcePools/vms/DMT003
or using the vmdk Object:
> vsan.object_info <ObjectUUID> ./localhost/DataCenterName/computers/ClusterName
Or using objtool or vsan obj health script on any host.
Or if using 6.5 U1 or later with esxcli from any host in the cluster:
# esxcli vsan debug object list -u <ObjectUUID>
or if you don't want to bother getting the vmdk Object UUID then just less the output of this or redirect to a file e.g.:
# esxcli vsan debug object list > /tmp/objlist.txt
If it is proportionalCapacity=100 then google "proportionalCapacity=100" "TheBobkin" and you will find 11 times on Communities I walked through it
b) VM was migrated/created with Thick primitive on the vmdk.
There is a Health UI check notifying of this in later builds (think just 6.7 but likely 6.5 U3 also), not positive but the vmdk descriptor may also have thin-provisioned line flag set to 0 indicating this. Cloning from a Thick-provisioned template/VM is another way this can occur. If there is little data on the vmdk (and it can't be vMotioned off vsanDatastore and back) then consider just adding a second disk of same size (and thin ) ,copying the data over within Guest-OS and removing original.
c) vmdk is full or was full at some point - vSAN doesn't auto-reclaim used, then freed space within the Guest-OS, TRIM/UNMAP is only available in 6.7 U1 and later - if you are not on 6.7 U1 then consider the options from b) to resolve this.