Steps to Run Iometer in a VMware VM?
Iometer is a great storage IO testing tool. It is easy to use, flexible, accurate, and free. Below are steps to run Iometer from within a Windows VM running on VMware.
Step1: Install the older 2006.07.27 edition. Don’t use the latest 1.1.0 edition which has bugs. Download link is here.
Change only the parameters listed below, keep all else default.
Step 2: After you install Iometer, run it with Windows ‘run as Administrator’ option. Each ‘Worker’ (screenshot below) is a process (or thread) that Iometer creates to generate storage IO on. The number of ‘Workers’ should be equal to the number of CPU cores assigned to the VM. Each CPU core can process only one Worker, so there is no point having more ‘Workers’ than that, because then the CPU on the VM will be choked. You don’t need large number of VM CPU cores to generate a lot of load either. Four to eight CPU cores assigned to the Windows VM is fine.
Iometer Screenshot: Configure Iometer Workers (Processes).
Step 3: For each worker, assign it a ‘Maximum Disk Size’ as shown below. This will create one file in C:\ that all the ‘Workers’ generate read and write IO to. The file should be large enough to overflow any memory buffers in the storage IO path, and small enough so the test hits all the sectors on the file quickly (say in under 30 minutes). 5-10GB is a good file size. Anything over 20GB is overkill and under 2GB might be served entirely from storage appliance memory.
‘# of Outstanding I/Os’ defines the number of concurrent IOs that each Iometer worker will generate. The higher the ‘# of Outstanding I/Os’, the higher the throughput that Iometer tries to push against storage. A Windows VM cannot push more than 64 IOs per VM, so if you multiply the Number of Workers with the ‘# of Outstanding I/Os’, the resulting value should always be kept under 64. A total IO depth of 64 is high. If you add up the IO depth of all your production VMs (assuming an ESXi cluster of 6-12 hosts), it is unlikely that the total number at any point will exceed 64. Now if you do want to test with higher IO depths, for instance, to see what the maximum throughput your storage is capable of, you can clone the test VM and run the same Iometer test in multiple VMs simultaneously.
Ensure that ‘# of Outstanding I/Os’ and ‘Maximum Disk Size’ are set the same for all ‘Workers’.
As an example, for Flash based storage, a 4-threaded (i.e. 4 workers) workload pushing 3-6 IOs per thread should exercise the entire 5 GB test file in 20-30 minutes. So, reviewing the Iometer stats at the end of 20-30 minutes should give you an accurate picture of your storage performance.
Iometer Screenshot: Set Test File Size and IO Depth Per Iometer Worker.
Step 4: Now for each ‘Worker’, assign it a workload, called ‘Access Specification’ in Iometer. As shown in the screenshot below, click on ‘Access Specification’ tab and assign it a Read/Write mix (80/20 is typical for enterprise wide traditional IT workload). Ensure that the workload is 100% random (since VMware workload is random) and the ‘Transfer Request Size’ a.k.a block size is 4KB (4KB is the average block size that Windows uses). Random small block IO is the most stressful for any storage infrastructure, so that’s another reason for these settings.
Iometer Screenshot: Set Block Size, Random IO, Read/Write Mix Per Worker.
Step 5: Click on ‘Results Display’ tab. Set the ‘Update Frequency’ and change the default ‘Display’ parameters to the ones shown below.
Then click the green flag icon at the top to start the test.
Iometer Screenshot: Display IOPS and Latency in Results Screen, and Run Test.
Wait for 20 minutes and then note the read / write throughput and latencies.
NB: If you want to mimic your real-life production workload using Iometer, then you need to plug the values for ‘Transfer Request Size’, ‘# of Outstanding I/Os’, and ‘Percent Read / Write Distribution’ for your production workload in Iometer. Please revie this blog post on how to quickly find those values for your real-life workload.
