Since there are many luns in a datastore, does this mean the vm's have used up the full 2.1TB from this lun and another 6.2TB from other luns in the datastore?
Usually you would map one physical block storage device (a LUN) to one VMFS datastore. Are you spreading a single VMFS datastore over multiple LUNs/extents? Anyways the Datastore CapacityGB value should always be the whole datastore capacity, no matter over how many extents it is spread. Anyways I don't think you were trying to say that and I have no idea where these 8TB VM used space come from in your case, but here are 2 guesses:
1. One possibility that I already mentioned are RDMs. Did you check if any of the VMs use RDM disks?
2. Another possibility is that a VM has files spread over multiple VMFS datastores or has an ISO from another datastore mounted. The script I provided just is pretty dumb and just adds the whole VM used space metric to the per-datastore total value, meaning the whole VM used space is added to every datastore even if it only has a small vmdk on it or ISO mounted from it.
I ran a few tests and actually found the VM used space metric to be completely unreliable in my environment with thin disks and vCenter 5.5U2 and ESXi 5.5 U2. I'm not sure how or if this applies to thick disks as well, but the per VM used space that is reported to me is in some cases a lot lower than what the vmdk flat files really occupy on the datastore when SSH'ing into a host and looking at the filesystem.
I've adjusted the script to cope with that by using values from datastore views instead of the unreliable VM UsedSpaceGB property. This should take care of point 2 I mentioned above as well. You will need to import Luc's function from here:
http://www.lucd.info/2011/11/14/storage-views-datastores/
Get-Datastore vnx_gold-01 |
Select Name, CapacityGB,
@{N='Datastore Used Space GB'; E={[math]::Round($_.CapacityGB - $_.FreeSpaceGB)}},
@{N='Datastore View VM Space Used GB'; E={ ($_ | Get-VM | % { $sview = Get-StorageViewDatastore -VM $_ | Select vDisk, Snapshot; [math]::Round($sview.vDisk.Value + $sview.Snapshot.Value + $_.MemoryGB) } | measure -sum).Sum } },
@{N='VM Space Provisioned GB'; E={ [math]::Round((($_ | Get-VM | Select -Expand ProvisionedSpaceGB | measure -Sum).Sum) +
((($_ | Get-Template).ExtensionData.Summary.Storage.Uncommitted | measure -Sum).Sum) / 1GB) } } |
FT -autosize
Note: It does not count templates and is runs a lot slower, so you might just want to test it with one datastore first.
If you still see large discrepancies then it's time to check the actual file sizes on the filesystem and compare it to each VM's reported space.
SSH into a host and do:
# du -hs /vmfs/volumes/vnx_gold-01/*
The sum of all folders should pretty much exactly match the datastore space used value (also see df -h). Each individual VM folder should match the reported Datastore View VM Space Used GB value from the list of VMs:
Get-Datastore vnx_gold-01 | Get-VM | Select Name, UsedSpaceGB,
@{N='Datastore View VM Space Used GB'; E={ $sview = Get-StorageViewDatastore -VM $_ ; [math]::Round($sview.vDisk.Value + $sview.Snapshot.Value + $_.MemoryGB) } },
ProvisionedSpaceGB | FT -autosize
Note: I'm adding the VM's memory size to the Datastore View VM Space Used GB there because of the earlier mentioned VM swap file. If you have a memory reservation the total will be skewed by the size of the reservation.