Hi Rene, I realise it's a little late, however been thinking about this...
From your output when NAGIOS reports against the volume is sees the same 43% used figure as OnCommand, so no issue there...we have a 43% used volume on the storage.
However, we do have the LUN showing more space than the volume...I believe this discrepancy is explained by Storage Efficiencies in thin provisioned block environment, i.e. LUNs.
VMware datastores dedupe very well; if for example the datastore in ESX is thick provisioned, i.e. it's been zero'd out, or has many VMs of the same OS, etc, then on the storage then these blocks will be mostly deduplicated. These savings will be shown in the volume capacity, but not the LUN.
Example: I have a test LUN with no snapshots...
test_lun | thin provisioned | 3.92GB available | 1.08GB Used | 5GB total size |
test_vol | thin provisioned | 5.12GB available | 0.3GB Used (much smaller!) | 5.15GB total size |
Volume Efficiency Savings in this example are:
- Dedupe savings 1.04GB
- Compression savings 13.57MB
- Total savings 1.05GB
We have 1.08GB used space in the LUN, however only 0.3GB used in the volume. However, if we add the total savings from the Storage Efficiencies to the volume used space it gives 1.08GB i.e. the used space in the LUN. You will be able to see the deduplication/compression savings for the volume using the command df –S or the Storage Efficiency tab for the Volume in System Manager.
However, that does not explain why ESX can see more used space than OnCommand. This could be down to any VM snapshots reserving additional space, or VM bug 2110199, fixed in 6.0 Update 1a.
If these were NFS datastores then both ESX and OnCommand would report the same capacity.
Hope this clarifies the figures for you.
Thanks,
Grant.