Microsoft announced on the Exchange Team blog today that they now support running Jetstress 2010 inside a virtual machine. You can read more about it and a little bit of the background on this one at the Exchange Team blog post here.
If you aren’t familiar with Jetstress, here’s a two second version: Jetstress is a tool from Microsoft that simulates the disk activity of an Exchange Mailbox server. It is used to simulate the load on the storage system used to host Exchange mailbox databases, and measures key attributes like disk I/O latency and total IOPS.
In my experience with Jetstress I’ve seen exactly what Microsoft has seen in the past. Namely, results from Jetstress (particularly I/O latency numbers) that do not match what is reported by either the ESXi host or the storage itself. So despite what Microsoft says here about the fact that Jetstress is now supported when run in a virtual machine, I still think it makes sense to independently validate the results.
As recently as last year I had a customer run Jetstress on their Exchange 2010 virtual machine that was running on vSphere 4.1 and the results were less than what we expected. Once we ran it again and measured the I/O latency in both esxtop as well as from the storage array management software we could clearly see the numbers were within the acceptable range.
Why would the numbers be inaccurate? Jetstress relies on in-guest timers to measure things like I/O latency, and so like any other in-guest timer they are susceptible to clock drift issues when the host’s CPUs become heavily loaded. A more common tool for testing Exchange performance, Load Generator 2010, relies on a separate client machine and so the numbers produced from that are generally considered to be more accurate (though it doesn’t test the same thing as Jetstress).
I can see why Microsoft has made this change – combine the fact that you can easily get 10 core CPUs with hypervisors that have improved considerably over the years and you are unlikely to see many issues anymore. For the most part you’re likely to see accurate test results unless the ESXi host itself is under heavy CPU contention.
Bottom line: I still recommend that results from Jetstress be validated outside the virtual machine using either esxtop or stats from the storage array, preferably both. If all three match up then you can feel confident that the data you’re seeing from Jetstress is accurate.