Having done my fair share of baselining Windows systems, and even blogging about it before - I finally took some time to dig a bit deeper into some of the data I had collected. One of the things I knew was that certain maintenance/operational procedures, like nightly backups, were elevating the average disk IOPS values. What I recently found at one site revealed the extent to which these averages could be elevated.
One particular physical server that was monitored with perfmon showed average disk IOPS of 5 and peak disk IOPS of 1208. What's interesting is that once the nightly backup window was excluded from these averages, the peak IOPS value dropped from 1208 all the way down to 391. That's a third of the first value! This server made use of direct attached storage and was being backed up over the network using an agent from a popular 3rd party software company. This server did not have regularly scheduled antivirus scans or defrag jobs running, but these activities would have certainly increased the disk IOPS averages as well.
When sizing physical servers for virtualization, one of the things to keep in mind is that certain operational processes and procedures will likely change along with the conversion. In most of the cases I have been involved with, the agent-based backups will be no more - Virus scans, defrags and other tasks may very likely remain. To appropriately size the required IOPS for this measured workload, I would exclude the data collected during the backup window. The awareness of peak IOPS that may not exist after a P2V conversion, becomes very important during sizing for virtualized systems. Depending on the criteria used for converting systems, knowing the true value of what the disk IOPS will be could make the difference between a system that gets virtualized and one that does not.
It is also important to note that disk IOPS are only one part of the sizing process. The same ideas apply equally to memory usage, cpu usage and network IOPS. Manually measuring with perfmon is a quick and easy way to size a server, but combining this data with complementary knowledge of what the physical systems are actually doing (and when) can lead to very accurate sizing estimates for P2V conversions.
Thanks for reading!