Специализированная, проприетарная файловая система VMware.

Ее отличительными чертами являются:

• минимальные накладные расходы - т.е. производительность при прямом доступе к диску сопоставима при доступе к vmdk файлу на этом диске. (за конкретными цифирками можно посмотреть сюда - Performance Characterization of VMFS and RDM Using a SAN - официальный whitepaper VMware)
  
• Поддержка файлов большого размера - до 2 ТБ.
• Кластерность - т.е. к VMFS разделу могут одновременно обращаться несколько хостов.

Когда идет штатная работа, т.е. есть несколько ВМ, которые обращаются к своим vmdk файлам на VMFS разделе, то:
производительность этого раздела(диска\LUN'а на котором он находится) делится между ними. По умолчанию, в равных долях, можем изменить эту настройку - в св-х ВМ, для ее диска есть возможность указать произвольные shares.

Но в некоторых ситуациях возникают дополнительные факторы, влияющие на скорость. Это ситуации, когда необходимо внести изменения в т.е. метаданные(metadata, метадата). Когда необходимо изменить метаданные раздела, используется SCSI Reservation для получения эксклюзивного доступа к диску\LUN'у каким то хостом. Таким образом, на время внесения изменения другие хосты(ВМ с них) ждут снятия блокировки. Слишком большое число таких блокировок может существенно снизить количество I\O, которое мы могли бы выжать из дисковой подсистемы. Таким образом, мы заинтересованы в минимизации их количества.

SCSI Reservation используются в следующих случаях:

• Создание и удаление VMFS хранилища
• Расширение (extent) VMFS хранилища
  
• Включение и выключение ВМ
• Получение или особождение блокировки файла
  
• Создание или удаление файла
  
• Создание шаблона
  
• Разворачивание ВМ из шаблона
  
• Создание новой ВМ
  
• VMotion ВМ
  
• Рост файла(актуально для файлов снапшотов или дисков (vmdk файлов) в режиме thin  - эти файлы не preallocated, т.е. на диске занимают только столько места, сколько реально весят файлы гостевой ОС. При необходимости, они растут, блоками по 16 МБ. )

Таким образом, не стоит делать много таких операций одновременно в часы пиковой загрузки.
Отсюда растут уши рекомендации разносить тестовые и производственные ВМ по разным LUN'ам - т.к. лоя тестовых ВМ характерен "рваный" режим работы - включения, выключения, перезагрузки, снятие снапшотов, откат на снапшоты и пр.

Бывает такое, что блокировка LUN не снимается. Чтобы определить такую ситуацию, поможет команда
esxcfg-info -s | grep -i -B 12 pending
Соответствующая тема на форуме - How to check if a LUN is being locked by a host.

Так же, полезно глянуть тут - Как работает VMFS.

---

Сколько ВМ может лежать на одном VMFS разделе?
Судя по этой теме на форуме, ограничений два: это достаточность I\O и ограничение на кол-во файлов(достаточность обьема я не учитываю как очевидную). Написано, что на VMFS разделе может лежать порядка 31 715 файлов. Это дает нам порядка 3000 ВМ(одна папка и 9-15 файлов на каждую ВМ, не учитывая снапшоты). Достаточно много, не так ли? Но, учитывая производительность, редко встречаются инфраструктуры более чем с полутора сотнями ВМ на одном ЛУНе, а обычное значение 7-30 ВМ, в зависимости от их требовательности к диску и скорости СХД.

---

Есть мнение, что по умолчанию один хост VMware ESX может иметь одновременный доступ к виртуальным дискам *.vmdk «на сумму» до 4 ТБ. Это меньше, чем заявленные 64 ТБ.
Чтобы подключить дисковых ресурсов больше чем на эти 4 ТБ, читаем что сделать тут - VMFS Heap Size для VMware ESX / ESXi.

---

Появился документик - VMFS Best Practices.

Еще - VMware VMFS Volume Management.