Forum Discussion

Paul_Armenakis1's avatar
Paul_Armenakis1
9 years ago

VMware Shared datastores - Latency tuning

We use shared storage in our VMware environment (and I would think most non-soho environments would as well). We have a problem where if we have a datastore that is shared among all of the hosts, if we want to change a latency threshold (or any other threshold) on this datastore, we have to do it on each host individually (also, in 3 separate datasources, ESX Host, ESX Datastore, and ESX Datastore performance, but thats besides the point). If i have 6 hosts, thats 18 points (3 in each host) that I need to adjust by hand.

It would be really nice if I could click on the group of ESXi hosts, expand the "ESX Datastore Performance" datasource, and see every single datastore across the entire cluster. Changing the threshold on one would change the threshold of every datasource with the identical name.

For example, if I had esx1, 2, 3, 4, and 5, and then datastore1, datastore2, and datastore3 spread across all 5 hosts, I would be able to click on my parent group in LM and go to "ESX Datastore Performance" and adjust the 3 datastores and have those changes propagate to all 5 hosts.

I asked support about this and Kurt said the only way to do this currently is to clone the datasource, filter out the new datasource to only be the specific datastore i want, and then filter that out of the existing. While that might work, its still creating a ton of work, and wouldn't scale with a ton of datastores.

Thanks!

  • Steve_Francis's avatar
    Steve_Francis
    Icon for Advisor rankAdvisor
    9 years ago

    Good point. Not a way to do this currently - but as a (minor) help - the current version of ESX Datastore- datasource does not monitor latency - that is carved out to the ESXDatastore Performance datasource. (Due to the fact that the way the former queries data is not compatible with getting latency from NFS datastores.)

    So that will reduce the ineffeciencies a little, if you update to the current version....

    We'll think about how to fix the other workflows.