Антон, позвольте с вами частично не согласиться. Я конечно понимаю, что вы большой специалист из EMC, но у меня на руках за последние месяцы тонны тестовых материалов, так что...
1. Теория IOPS - это хорошо, но на практике не всё так гладко. Начнем с того, что у SAS в 3 раза меньше задержки (примерно 3 против 9). Потом, у SATA длина очереди 32 против 256 у SAS. Уж не знаю как там с теорией, но на практике RAID5 SAS 10к и RAID10 SATA 7.2к из примерно одинакового количества дисков работают ну с очень разной скоростью. И по пропускной способности и и особенно по латентности. Естественно, ВМ на этих датасторах ведут себя совершенно по разному.
При работе в 1 поток с дисковой подсистемой (думаю, процент таких приложений устрашает) всё упирается в её латентность. Пример: у нас гипотетическая хранилка на SATA, выдающая 5 миллионов IOPS (пусть такм миллион дисков будет), противопоставляем ей хранилку на SAS, которая выдаёт 1000 тех же самых IOPS. И вот у нас приложение пытается в 1 поток писать (или читать) с такой хранилки SATA. Задержка пусть будет 9ms. 1000/9=111 IOPS. Это тот максимум, который получит приложение. Что же у нас с SAS? При задержке в 3ms приложение получит уже 333 IOPS. И больше, и более отзывчиво. Так что не все йопсы одинаково полезны, как говорится. Их еще и реально получить как-то надо, а вот с этим возникают проблемы.
Ну, и открою всем очевидную тайну (вроде она на поверхности, но озвучивается редко). Все уровни RAID на чтение имеют практически идентичные IOPS. А вот запись сильно отличается. В принципе, Антон уже коснулся этого тезиса чуть выше.
2. Про дровишки. Уж вам ли не знать принцип работы гипервизора ESXi? ВМ работает с тем типом контроллера, который установлен для неё в виртуальном железе. И прослоек с различными виртуализациями систем хранения там как минимум 4 штуки, а может быть и более. Последними слоями занимается RAID контроллер и мозги самих дисков, а вот первые разгребает госевая ОС и гипервизор. ОС работет с диском, подозревая что это некий скази и шлёт ему соответствующие команды. В этом момент гипервизор снимает машину с физических ядер и отправляет в очередь WAIT, подделывая при этом запросы ВМ в необходимый гипервизору вид для общения с системой хранения (это может быть что угодно, iSCSI, FC, SAS, SATA и т.д.) Так что команды внутри ОС гостя и команды общения гипервизора с системой хранения - это действительно 3 большие разницы.
Кстати, раз уж тема зашла про IOPS, давайте я всем мозг взорву. На IOPS ВМ влияет не только тип и производительность системы хранения, но и процессы, происходящие внутри ВМ. А точнее параллельные обращения ВМ к вводу-выводу, а так же текущая нагрузка на процессоры хоста. Всё сказанное достоверно на 100% для iSCSI, но по видимому и для FC тоже актуально (надо проверять).
Итак, тестовый стенд:
2хXeon E5 2690
394 GB RAM
2x10 Gbit LAN Intel X540 T2
Хранилка 2xXeon 2609 + 192 GB RAM + Starwind 6 + Ramdrive 100GB + iSCSI 10 Gbit
Свитч Dell 8024 10 Gbit
Измеряем IOPS при помощи IOMETER, 100% случайное чтение в 1 поток блоками по 4к
Итак, физическая машина, будучи подключенной к этой системе хранения снимает 90к+ IOPS в один поток.
Измеряем из ВМ, (2 vCPU), получаем 4000 IOPS в 1 поток (в 256 потоков 90к IOPS тоже снимаются)
При этом нагрузка на процессоры хоста практически 0
По показателмя esxtop GAVG=DAVG= 0.22ms
Теперь нагружаем другими ВМ процессоры хоста до 80%.
Измеряем из ВМ, получаем 1900 IOPS в 1 поток!!!
esxtop GAVG=DAVG= 0.4ms (как так? у нас система хранения виновата? Да ну?)
Убираем нагрузку с процов хоста, тестовая ВМ опять одна.
Но пробуем работать с сетью (у хоста 2 сетевых адаптера, один выделен под iSCSI, воторой под работу с сетью)
Копируем из сети большой файл и кладём его на диск ВМ (другой диск, не тот, который меряется на IOPS, он физически лежит на другой системе хранения)
Измеряем из ВМ, получаем 2000 IOPS в 1 поток!!!
esxtop GAVG=DAVG= 0.32ms (опять?)
Ну и для верности
Пробуем работать с чистой сетью
Копируем из сети большой файл и кладём его обратно на сеть, то есть дисковая подсистема вообще никак не нагружается дополнительно.
Измеряем из ВМ, получаем 3000 IOPS в 1 поток!!!
esxtop GAVG=DAVG= 0.31ms (и снова?)
Вот такие вот интересные показатели. Так что теория IOPS у систем хранения и практика VMWare не совсем равны. Продолжаю наблюдения...
P.S. ИМХО, во всём виноваты постановки ВМ в очередь WAIT при работе с вводом-выводом. Больше ничем не могу объяснить такую картину. Ответ ищу уже давно, но все молчат, в том числе гугл и специалисты VMWare. Может вы чего подскажете?
Ну, и просил коллег на других системах померить максимальные IOPS в 1 поток. Тоже упёрлись в 4000. Магическое число... И на Hyper-V тоже в 4000 упёрлись. Хранилки использовались правильные 2-головые, тоже на iSCSI 10 Gbit. Диски SSD.
Кстати, смотрел документацию на свитч Dell, который использовался в тесте. Так вот, он по идее даёт задержки в районе 3-4 микросекунд (0.003-0.004ms). Вероятно, оно тоже виновато.
P.P.S. К чему я это всё? А к тому, что если у вас машина интенсивно работает с вводом-выводом, и не дай Бог еще и параллельно с диском и сетью - то тормозить она будет качественно 
Как вариант, сервер баз данных Но надо признать, что VMWare прямо не рекомендует виртуализовывать сервисы, имеющие гиперактивный ввод-вывод.