I have an EVA 8000 (latest firmware) and a 1.2 TB lun presented to two blades that I plan on running around 5 vm's each - all ten will will be Windows 2008R2 64bit guest os's. I've made to it to creating two of the 2008 vm's and they are in production (they answer .net requests) - the write latency is the bursts up to 200-300 ms for up to 30-40 mins - as I understand it this is terrible performance. The disk group I've created is made up of 9 450Gb 15k rpm drives - I've looked and looked on the web and see people talking about seeing high WRITE latencies like this (the read latencies never go above 2-3 ms) on the web, but no Definate answers...
Can someone at least point me in the right direction for a best practices guide related to Esxi **5** and Eva 8000? Has anyone here seen write latencies like this?
Btw there are no other vdisks in the disk group -
this indeed is quite high...you may want to start with verifying your setup against the EVA best practices guide below:
Best practices guide related to Esxi **5** and Eva 8000?
1. Setting the Maximum Outstanding Disk Requests:
2. Disk.IO.Max.Size parameter
3. Queue Depth: (Making this Changes be Careful as need to Re-Install the OS)
In this case, the HBAs represented by ql2x and lpfc0 will have their LUN queue depths set to 64. (default is 32)
After Changing the Settings shows error /bin/sh: can't access tty; job control turned off. and give the option to boot from
troubleshooting mode,after booting from troubleshooting mode it works properly but not able to connect in Vcenter Server and
not able to see the datastores in the ESX Host.
HP StorageWorks Enterprise Virtual Array (EVA) - Performance Issue and Best Practice to Optimize EVA Performance
Thanks for help -
As it turns out - one of the controllers on our EVA 8000 is completely busy - this was verified w/ evaperf and tlviz formatter - I changed the managing controller for the vdisk from B to A and write latencies are almost non-existent. I just thought I'd post what the problem was since so many posts end with not knowing whether the probelm was solved or what the problem turned out to be.