Write IO size for datastore using derived metrics

Hi Petrisor, 

Looks like IO size, also known as block Size, is available via vSphere API https://www.vmware.com/support/developer/converter-sdk/conv55_apireference/vim.host.VmfsVolume.html . It looks like the VMware cartridge does not collect this data at the moment.

Could you please explain why do you need that formula for Latency? what is wrong with the latency metrics provided by VMware (see link)

https://www.vmware.com/support/developer/converter-sdk/conv61_apireference/datastore_counters.html 

Gaston

We have VMs with windows 2008 server that when performing some tasks will utilize large I/O block size with an average of 200 KB, because of this latency is reported high on the volumes where VMs are located. Vmkernel issues IOs block size of 32k. That is the reason for which we need to calculate latency with this formula.

kb.vmware.com/.../search.do

I understand now, you are trying to solve some false positive alerts generated at the array and seeing by Foglight/vSphere. This seems caused by Windows 2008 issue.

The KB you pointed out, shows this false positive could be avoided by modifying windows 2008 registry to issue smaller I/O block sizes. Could you try solving the issue where it originates?

• Large I/Os Are Split into 64KB Units When Using LSILogic Driver (9645697) 
• The Guest Operating System Storage Considerations section in the Performance Best Practices for VMware vSphere 5.0.

Hello Gaston,

Probably I was not very clear.  Not only with windows 2008 we experience high latency false positive. That's why we need to calculate latency with this formula.

Thank you.

Hi Petrisor,

Thanks for the clarification. This seems more complex than what I expected. We receive the latency metrics from vSphere, to my understanding, to solve the false positives, the logic should be: Once high latency has been detected for the datastore, the rule will have to check if the Virtual Machines in that datastore are issuing large block sizes.

Another option, could be a rule that checks for VMs issuing large block sizes and alert that, this should allow you to apply the solution for the OS issuing the large blocks, and prevent the false positives.

Other solutions are:

1) Have PSO to do this for you.

2) Add this functionality to FVE. 

Regarding option 2, I will sync with one of our Product Managers and see if this use case could be valuable for other customers, if so I will provide a enhancement request number.

Question, did you reach VMware to see if they could handle the issue on their end?

Gaston.

Hi Gaston,

In my case first option should be better because we are not managing OS layer ( Once high latency has been detected for the datastore, the rule will have to check if the Virtual Machines in that datastore are issuing large block sizes.)

Thank you.

Petrisor

Hey Gaston,

I have open SR# 3663374

Thank you.