почему-то я так и подумал, что первый ответ будет таким 
Из-за других vm работающих на этом сервере, - их много, esxi бесплатен, стабилен и позволяет динамически перекидывать оперативку между ними. А пользователь один -я.
Принципе главный вопрос - с какой операционной системой собрать vm, какую файловую систему использовать для хранилища при моих условиях?
Это не один, а два вопроса. :smileygrin:
Сразу прошу извинить относительную пространность (ну, с т.з. профи ) - Вы сами обозначили себя как начинающего, так что немного ликбеза в гомеопатических дозах не повредит. :smileygrin:
По первому - на основе чего NAS.
Наверное, на той ОС, которую Вы лучше всего знаете/понимаете.
Но в целом при Вашей ситуации можете взять какой-нибудь коробочный дистр с минимумом телодвижений.
Например, OpenFiler.
Да, он "заморожен" и больше не развивается, но даже на многое железо до сих пор встаёт "на ура" (как пример - Xeon`ы 1366/2011, SATA/SAS-контроллеры 6Gbit, Ethernet 10Gbit).
На виртуалку же он заходит, как дети в школу.
При этом он реально "интуитивно понятен и дружественен" даже для начинающего, да и материалов по его установке/настройке в Сети хоть пруд пруди. Берите 2.99, 2.3 менее актуален. Реально "дубовый" дистр в самом хорошем смысле.
Чтобы не быть голословным, скажу, что у самого все хранилки - на работе! - крутятся именно на OF. В сумме там полсотни терабайт и в ближайших планах утроить этот объём ещё парой хранилок на OF (одна боевая SAS, вторая архивная на entrprise SATA).
Работает на них четыре десятка виртуалок - собственно, вся продуктивная инфраструктура, на "физике" у еня остались только элементы VI - хосты и хранилки.
Ага, уже не первый год обещаю себе переползти на что-то более стильное, модное, молодёжное современное - даже собирал себе ЦентОС с SCST-таргетом... но воз и ныне там: то лень, то некогда... а OF крутится и крутится себе. Но, чую, ща с переходом на 12Gbit контроллеры (SATA/SAS) придётся всё же заменять OF на "самокрутки".
Так что попробуйте сделать тестовую VM с OF и поиграйте с ней - не пожалеете. :smileygrin:
По второму вопросу - тут сложно.
Вот Вы говорите:
Цель - сетевая шара c nfs, iscsi,webdav
Применительно к iscsi слово "шара" может послужить причиной многих трагедий
iscsi - блочный доступ, сама хранилка на LUN (разделе), презентуемом по iscsi другим хостам/компам, никакую ФС не делает - файловую систему на этом LUN создаёт хост-инициатор (iscsi-"клиент" хранилки).
Если хост-инициатор будет виндовой машиной, то iscsi-LUN от таргета (Вашей хранилки) её диск-менеджер "увидит" как ещё один локальный диск - и Вы сможете создать на нём, например, NTFS.
Если хостом-инициатором будет Мак, то на этом iscsi-LUN`е будет созданная им HFS.
А попытка отдать LUN по iscsi на запись двум или более компам-инициаторам чревата гарантированной потерей данных - если у Вас только не будет на этом LUN КЛАСТЕРНОЙ(!) файловой системы.
"Локальные" ФС - NTFS, FATxx, HFS, extN, xfs, reiser и иже с ними кластерными НЕ являются!
Поэтому попытки работать с "шарой" (именно так - в кавычках") iscsi в привычном стиле работы с файловыми шарами - это больно и неприятно.
Вот когда речь идёт о файловых шарах - тогда за ФС, на которую эти файлы лягут с сетевого компа по файловому сетевому протоколу, отвечает ОС хранилки. И она же регулирует совместный доступ к этим файлам с разных компов по сети.
При Ваших условиях - вполне вегетарианских и игрушечных по правде говоря - лепить на хранилку ZFS, это как вспахивать одну грядку под морковку с помощью трактора К-700 с семилемешным плугом. Избыточно, короче - и весьма.
ZFS больше чем ФС - и закончим на этом, ОК?
В Вашем случае выбор той или иной системы (дистрибутива) для VM-хранилки автоматом определяет список ФС, которые это ОС сможет сгенерировать.
Скажем, если Вы слепите хранилку на вин-сервере, то Ваш выбор ограничится одним пунктом - NTFS (не, FAT32 тоже теоретически возможна, но это несерьёзно ).
А хранилка на линуксе (к коим относится и тот же OF) даст возможность использовать набор ФС: ext2/3/4, xfs, reiserFS, etc.
И тут выбор делать Вам. Критерии выбора разные, тут надо смотреть на сильные и слабые стороны.
Например, одни не блещут по скорости (относительно, конечно - по сравнению с "чемпионами"), но надёжны и устойчивы к сбоям (хорошо чекаются при рестарте, иеют богатый набор утилит восстановления и т.д.).
Другие - ровно наоборот. Третьи - частично то, частично это.
Тут я Вам не подсказчик, могу лишь сказать, что при приемлемом уровне железа я обычно поступаюсь "родными" спринтерскими качествами ФС в сторону бОльшей надёжности ("передавливаю" железом софт, тсзть. Но это не догма.
Вот вкратце как-то так...
И вдогонку, чтоб не раздувать предыдущий комментарий... :smileygrin:
По вопросу ФС - я сразу не заметил, что у Вас крайне специфическое видение этой проблемы/задачи (и в данном случае это не похвала! 
)
Отсюда возникает вопрос - проблема сохраняется если используется прослойка в виде vmfs6?
vmfs нужна самому гипервизору (ESXi), чтобы размещать на ней файлы виртуальных машин (ну и прочие необходимые ему).
С т.з. как ОС виртуалки, так и ФС внутри этой ОС, на её "диске", VMFS "снаружи" не существует!
ОС "думает", что работает на "просто компе", а стоИт он в серверной или под столом, крутится ли в виде VM в гипервизоре - ХЗ, ОС виртуалки это не известно (технически это не совсем так, но это в данном вопросе абсолютно непринципиально).
Иначе говоря, если - а точнее, когда - ZFS или иная ФС дурканёт, то совершенно без разницы, будет ли "под ней" VMFS или физические сектора HDD (ячейки флеша SSD).
Высокая защищённость от сбоев(содержимое шары, backup не запланирован).
Какие файловые системы с проверкой содержимого менее ресурсоёмки - btrfs, refs, ...?
Товарищ, скажите, Вам настолько пох Ваши данные (выразился бы грубее, но стесняюсь)???
И кто Вам напел все эти военные песни (про zfs в частности... ну, в контексте надёэности, восстановления и пр.).
Я, блин, админ с почти четвертьвековым стажем, парюсь по рейд-конфигурациям носителей, зеркалированию и скрабингу модулей памяти (с ЕСС!!) на своих серверах, угораю по сдвоенным-строенным питальникам на разных UPS`ах и фидерах, мультипасу через разные коммутаторы, репликации нод и пр. - и при этом просыпаюсь ночами в холодном поту от кошмара, в котором все мои быкапы и архивы накрылись женским половым органом (ну ладно, тут вру :smileygrin: - не просыпаюсь... и просыпаться не хочу от такого )...
А Вы, ничтоже сумняшеся, в явном виде предаёте анафеме саму идею резервного копирования, уповая на какие-то полумифические способности ФС к (само)восстановлению и корректировке... да просто верите в её тотальную и незыблемую безглючность ныне, присно и во веки веков, аминь!
Поймите, быкапы - это последняя линия обороны и зачастую последний шанс "удержаться на краю" когда - не если, когда!!! - обосрутся, пардон май френч, все предыдущие решения по "отказостойчивости" (включая и редундантные сущности).
Привет Вам, кстати, из прошлого лета, от весёлого парня - Петя-шифровальщик зовут. :smileygrin:
У туевой хучи народа "абсолютно надёжное" оборудование на супер-пупер ФС содержало нечитаемый мусор.
И тем, у кого не оказалось быкапов/архивов пришлось оооочень несладко.
Просто учтите это.
отвечаю на работе, в "перекур", тсзть, поэтому пропускаю кое-что (а редактировать уже отправленный комментарий бывает проблематично - то ли сайт тут чудит, то ли браузер мой капризничает )
Выяснилось, что компании с крупными бюджетами не спешат с поддержкой своих продуктов. LSI до сих пор не выпустил smi-s provider под 6.7 так что я,даже не вижу, что там с массивом. Опять ждать у моря погоды.
Я бы не стал тут пинать LSI - ну, именно за этот аспект (за тупую, тормозную и глючную JAVA-морду их MSM я бы убивал с особым цинизмом :smileygrin::smileygrin::smileygrin:).
Просто Варя чота стала угорать по Аджайлу это то, что раньше называлось х.як-х.як и в продакшен - в результате вменяемые админы (а таких в нашем цехе всё же большинство ) до U1/SP1 на новую мажорную версию не переходят.
Ну и LSI, видимо, не сильно рвётся бежать впереди паровоза - тем более, что парадигма Сферы и окололежащей экосистемы в том, что это решение в первую голову для крупняка, для которого локальный стор на рейд-контроллере непосредственно в хосте гипервизора скорее исключение, нежели правило - рулят сетевые хранилки (NAS/SAN).
Да даже Варина конь-цепция vSAN не предусматривает обязательного применения рейд-контролеров (так, как приятная опция и лишний уровень редундантности) - упор делается на "зеркалирование"-дублирование хостов и их сторов из отдельных дисков на HBA.
P.S. Лично я вообще сижу на Сфере 5.0, т.к. всё устраивает и обилие фичЪ 6-го семейства, как по мне, пока не окупает геморроя с переходом и последующей эксплуатацией (принципы-то базовые всё те же).
Так что когда/если буду переходить дальше по версиям, то не на самую свежую, а на предыдущую - обкатанную и обтёсанную (в т.ч. и со SMIS-провайдерами :smileygrin:).
так, я освежил свою память по спекам - вопрос снимается
контроллеры - включая Ваш 9266 - реально стараются придерживаться "сквозной" презентации именно размера сектора - то есть они могут (при соответсвующей опции в прошивке) менять только компатибабельность, презентуя диски 512Е как 512Т и наеборот
а размер сектора они отдают "наверх" без изменений
вот кстати плюс сетевых хранилок версус локального рейд-стораджа хоста ESXi - легче маневрировать версией ОС в сторону нативно понимающей сектор 4К
