Thanks for the response.  I am actually using the Netapp Management Console.  I should not have said DFM.  

So to rephrase my original statement, the Netapp Management Console is reporting VERY different numbers than the vSphere Consoles counters for the virtual machines disks.     Just trying to account for the difference in accounting between the NetApp Management Consoel and the vSphere disk counters for the virtual machine.   

-Phil




On Tue, May 21, 2013 at 4:26 PM, Klise, Steve <klises@sutterhealth.org> wrote:

·        May want to check for alignment of your vm’s.  If you have virtual storage console installed, its under monitor/host config, and tools.  Check it out.

 

·        Could be a reallocate issue if you have added a bunch of disks, but is doubtful. 

 

 

DFM is a used mostly for reporting among other things, but I use it primarily for reporting/protection manager, etc.  The Netapp Management Console is your friend.  That is the live view or a more “accurate” view of what is currently going on, with the ability to go back in time.  DFM is just going to show an average, and is not (IMHO) a good place to look for performance numbers..   Perfstat is the real ticket; that will show you console activity.

 

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Philbert Rupkins
Sent: Tuesday, May 21, 2013 2:19 PM
To: toasters@teaparty.net
Subject: VM Virtual Disk Latency Versus NFS Latency on Filer

 

Hello,

 

This may be more of a VMWare question.    From within Data Fabric Manager, I am seeing a spike in latency on a NetApp volume used as an NFS datastore.    DFM shows a spike in NFS latency of 50 ms on the volume.

However,  a virtual machine's performance counters in vSphere show a spike in Virtual Disk latency upwards of 700ms for the same "latency event".   

Any idea what might account for this difference in latency reporting between the NetApp (DFM) and ESXi?   I expected there to be some difference for obvious reasons but I didnt expect to see a difference of this magnitude.

 

Thanks,

Phil