Hi RS_1, that's helpful, but I was looking for some additional guidance to the user guide.
I got the answers from some of the I/O Analyzer developers, and also ran a few tests of my own.
Iometer generates its I/O based on the number of blocks of the target disk (i.e. the manually added virtual hard drive on the worker VM). The size of the virtual hard drive will be equivalent to the I/O working set size.
For a virtual hard drive that hits cache only, a rule of thumb would be to size it at 100MB.
For a virtual hard drive that hits disk, the virtual hard drive could be sized anywhere from 10GB upward. The larger the disk, the more I/O is actually hitting disk rather than cache.
To verify this, I created a 200GB thin provisioned virtual hard drive for my I/O Analyzer worker VM. As I ran the Iometer workload, I could see the thin disk quickly grow from nearly nothing to its fully provisioned size. This means that new sectors on the virtual hard disk were continually being read and written by Iometer. Interestingly, it only took about 5 minutes to flesh out an entire 200GB disk. Obviously this speed would depend on the type of I/O profile used.
I also tested Iometer on a 20GB virtual disk vs a 200GB virtual disk. Average latency, IOPS and throughput were all better for the 20GB disk - because a greater proportion of I/O in that case was hitting the cache, skewing the numbers positively.
So, even at virtual hard drive sizes past 10GB, size of the virtual hard drive will still affect observed performance for Iometer.