Debian 3.16.0-4-amd64, mysql Ver 15.1 Distrib 10.0.30-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2, 2 VCPU, 4GB RAM, VMware ESXi 5.5.0 build-2068190.

Hi Érick!

Do I understand correctly from provided graph,
Snapshot was taken about 11:45 AM and then it grew by more than 30 GB till 7:00 AM when it reached the capacity of that datastore?

Clould you post a Key and a screenshot of the item collecting metrics for that datastore.

Best regards,
Edmunds

The issue is on the VMware side:
https://kb.vmware.com/s/article/2110199

Can confirm that while there is some data written to the storage those counters are not updated. Only when writing process stops you get correct data.

The referenced KB is applied on the ESXi host.
About the previsous questions :

"...Snapshot was taken about 11:45 AM and then it grew by more than 30 GB till 7:00 AM when it reached the capacity of that datastore?"

Answer: Yes, the capacity was reached about 07:00 AM.

"Clould you post a Key and a screenshot of the item collecting metrics for that datastore."

Answer:The item used are :

vmware.hv.datastore.size[{$URL},{HOST.HOST},8_ALM_Primary_DB_Datafiles,free]

The requested screednshot was attached.

Now we are doing another test and the issue it's happening again. In other datastore we transfer a file directly to the datastore (not to a VM) and the space did not change for Zabbix.
I attached two NEWs images that have the value mismatch. On ESXi, the value are 950GB (correct) but on Zabbix still 961GB.

As I found out from developers - zabbix is getting storage info from configuration data instead of performance counters.

Also testing shows (esxi 5.5, 6.0, 6.5) that zabbix won't get info on storage changes unless triggered manually only on vSphere 6.X config is updated every 30 minutes and storage usage changes are updated.

Workaround is to regularly trigger storage rescan via api or Powercli

It caused a regression - ZBX-15142