VMware Cloud Community
WarlockArg
Enthusiast
Enthusiast

Doubt about Write Latency observed in Datastore

Hi,

   I'm having the following doubt. I have a VM with a virtual disk that resides in a local Datastore backed up by 7 SAS disk in RAID5. The virtual disk was created as Thick Provission Lazy Zero. I am running inside the VM a storage software (Datacore) which zeroes each disk that is added to a new pool.

   So, I added the VM's virtual disk (which is observed as a local disk inside the VM) to a pool in DataCore software and it begins to write all zeros in all the whole disk.

   When I go to vSphere Web Client and I look at the VM's Datastore Write Latency (it is to say, I have the VM selected in the inventory, and I go to the performance advanced chart, selecting the Write Latency counter) I observe a constant one of 2ms (perhaps some spikes to 5ms, but the average is 2ms).

   But if I observed the same counter but having the ESXi host selected in the inventory, I observe that the write latency on the SAME Datastore is 15ms.

   It is the only VM having activity in the host, so, the only VM issuing commands on that Datastore is the one I am describing.

   How can be possible that I observe a smaller write latency at the VM level than the one I am observing at the host level? It is supposed the latency increases as the command is going down from the VM to the disk, and not the opposite.

    What those counters are telling me is that the VM is receiving the ACKs quicker than the host! It sounds impossible.

   

    Could be possible that the cause of this behaviour it because the virtual disk in the VM is in Lazy Zero format instead of Eager Zeroed?

Thanks in advanced,

Guido.

0 Kudos
1 Reply
AishR
VMware Employee
VMware Employee

There have been instances where the information on the vSphere Client or vSphere Web Client is not sync up with esxtop. Might be beneficial to look at the esxtop real-time data also. Need to also look at Using esxtop to identify storage performance issues for ESX / ESXi (multiple versions) (1008205) | V...