Недавно тестировали vGPU на vSphere 6.0 + View 6.1 + NVIDIA GRID K2 с гостевыми ОС Windows 7. Все работает весьма шустро, поддерживается DirectX 11, OpenGL 4.0.
Также заметил, что в некоторых тестах vGPU профили с меньшим объемом видеопамяти (K260Q) могут демонстрировать лучшую производительность. Использование пофилей K280Q вообще не очень целесообразно, т.к. можно отдать ядро видеоадаптер напрямую (режим vDGA), единственный плюс vGPU в этом случае — чуть более простая настройка аппаратного ускорения внутри гостевой ОС.
Бенчмарк SPECviewPerf, по-сути, единственный широко применяемый тест, но его результаты сильно зависят от частоты процессора, поэтому не стоит удивляться ситуации, когда на какой-нибудь средненькой рабочей станции Core i5 с 4-я ядрами, результаты будут заметно лучше, чем на сервере с 16-ядерными Xeon с меньшей частотой.
Что касается Windows Server, то их можно использовать в качестве гостевых ОС в VDI вместо Windows 7, но нужно обращать внимание на то, какие функции VDI не поддерживаются в Windows Server.
Если вы планируете разворачивать VDI на базе VMware View, то можете купить лицензии Horizon View Standard Add-on, они не включают в себя лицензии на гипервизор vSphere for Desktop и vCenter for Desktop и стоят дешевле, чем обычные бандлы Horizon View Standard. Переплата все равно есть (зависит от плотности размещения ВМ на одном сервере), но за эти деньги вы получаете лицензии vSphere, которые можно использовать не только для развертывания VDI инфраструктуры.
Согласно спецификации EVO:RAIL конфигурация одного сервера на 2.5" дисках включает в себя 1 x SSD на 400 ГБ и 3 x HDD по 1.2 ТБ, что в сумме на одну коробку дает 1.6 ТБ кэша на SSD и 14.4 ТБ хранилища на HDD. Для максимумов эти цифры умножаются на 4.
Все серверы EVO:RAIL объединяются в один кластер, в котором настроен vSphere High Availability, DRS, VSAN. Миграция ВМ выполняется при помощи vMotion.
Сколько узлов одновременный отказ держит VSAN? :D
Гарантированно — столько, каков показатель Fault to tolerate. При оптимистичном сценарии — в VSAN данные доступны, пока доступно более половины компонентов и хотя бы одна полная копия данных.
Учитывая то что Nutanix показывает выдающиеся параметры производительности, и не имеет лимитов по размеру кластера
Делать неограниченный по размеру кластер — не всегда хорошая идея. Иногда несколько кластеров меньшего размера более оптимальны. Учитывая, что размер кластера VSAN (32 узла) равен размеры кластера HA/DRS, то это небольшое ограничение.
SSD в VSAN — это просто кэш, который крайне неэффективно расходуется.
А можете написать поподробнее — почему неэффективно? В VSAN данные в кэше на чтение хранятся однократно, один объект может быть разбит на несколько компонентов, каждый из которых может хранится в отдельной дисковой группе, а значит, использовать отдельный SSD по кэширование операций чтения.
Это в теории. А на практике, для VSAN / EVO:RAIL бурно сокращают HCL список, ибо у клиентов возникают серьезнейшие проблемы.
Про сокращение HCL — речь об исключении Intel AHCI в финальном релизе VSAN? У вас, насколько я знаю, он тоже не используется.
У VSAN есть свои плюсы:
-Возможность хранения от 1 до 4 копий объектов (у Nutanix 2 или 3).
-У VSAN кол-во копий, размер резервируемого кэша, thin/thick provisiong задается с помощью политик на уровне ВМ и отдельных виртуальных дисков, у Nutanix — это нужно делать на уровне датасторов ВМ.
-Отсутствие легаси в виде виртуальных апплайнсов, которые отдают датастор по NFS.
-Возможность установки в один сервер до 5-и SSD и до 35 жестких дисков (у Nutanix — в зависимости от модели, но не более 20).
-В целом, более широкий перечень поддерживаемых конфигураций оборудования.
-Возможность ограничения размера fault domain'а в рамках одного хост сервера за счет создания нескольких дисковых групп.
-VSAN входит в состав старших редакций View.
Так что сравнение Windows 3.11 и MacOS 10.10 выглядит несколько натянутым.
Интересует ваше мнение (как официального представителя) — по какие задачи не следует предлагать Nutanix? С физическими серверами — понятно, интересуют другие варианты. С ходу я смог придумать такие:
1) Развертывание Monster VM (64 vCPU, 1 TB RAM) под задачи какой-нибудь большой-большой СУБД или ERP системы. Конфигурация самой старшей ноды (NX-9040), на текущий момент, слабее лимитов гипервизоров.
2) Требование к дешевому дисковому пространство (например, для хранения бекапов или файлопомойки). В NX-8150 установлено 20 x 1 TB дисков, классическая архитектура с какой-нибудь JBOD полкой или просто дешевым массивом позволяет устанавливать более емкие 3.5" диски с большей плотностью размещения.
3) Малый (сверхмалый :-)) бизнес или бранч-офис. У меня нет под рукой прайс-листа Nutanix, но полагаю, что для небольшого бранч-офиса купить 2-3 обычных сервера и выделенный массив или дисковую полку, подключаемую по SAS, выйдет дешевле, чем купить NX-1020.
4) Использование Infiniband и всевозможных ускорителей (NVIDIA Tesla, Intel Xeon Phi).
Что вы думаете по поводу приведенных выше примеров? Возможно что-то еще?
В Microsoft Hyper-V RemoteFX работает с видеокартами обоих производителей.
В VMware vSphere в режиме vDGA могут пробрасываться и видеокарты NVIDIA, и AMD. Для режима vSGA поддерживается крайне небольшой список видеокарт: NVIDIA GRID K1 и K2, а также AMD FirePro S7000, S9000 или W7000.
Что касается Citrix, то для GPU Passthrough, опять же, нет особой разницы, что прокидывать, но в официальном HCL Citrix присутствуют только карты NVIDIA. Для Virtual GPU, действительно, поддерживаются только GRID K1 и K2.
Если бы такой десктоп поставлялся не только с Chrome OS, но и с другими ОСями, то был бы неплохим вариантом офисного ПК начального уровня. Учитывая, что HP для него еще и CarePack'и продает, так вообще замечательно. А так — штука больше для информационных киосков в публичных местах подходит.
Заметил одну странную тенденцию — если до внедрения серверной виртуализации я занимался обновлением firmware, ОС и приложений на серверах, то теперь я еще и гипервизоры с ПО управления обновляю. :-)
Начиная с ESXi 5, Apple Mac OS X официально поддерживается в качестве гостевой ОС — гайд по установке. Однако существует ограничение — такая конфигурация является совместимой, только если физическая машина — брендовое железо Apple, в частности: XServe 3.1 или MacPro 5.1 (список поддерживаемого железа). Кроме того, у гостевой ОС Mac OS X достаточно ограниченный список поддерживаемого виртуального оборудования.
Неправильно сравнивать гипервизоры второго типа (Oracle VirtualBox, VMware Player) с первым типом (KVM), у каждого свои задачи. Oracle VirtualBox и VMware Player/Workstation проще в установке, лучше работают с графикой и звуком, имеют более функциональный графический интерфейс, позволяют пробрасывать папки с файлами внутрь гостевой ОС, позволяют drag-n-drop'ом копировать файлы между гостевой и хостовой ОС, для них проще копировать и переносить ВМ с одного компьютера на другой, при работе интерфейс гостевой ОС можно прозрачно интегрировать с хостовой ОС (seamless mode, Unity), VMware Workstation помимо этого умеет шифровать диски, интегрироваться с другими решениями компании, вроде VMware vSphere, VMware ACE.
Если же сравнивать с гипервизорами первого типа (VMware ESXi, Microsoft Hyper-V, Citrix XenServer), то и тут KVM далеко не самый-самый. У каждого решения есть свои плюсы и минусы.
В RAID 5 чтобы записать данные происходит 4 операции (Чтение существующих данных, четность RAID, Запись новых данных, Запись новой четности) тем самым пенальти в RAID 5 составляет 4.
Эти расчеты актуальны до тех пор, пока записываемый блок данных меньше или равен чанку, из которых состоит raid. Если же блок записываемых данных больше, или, банально, файловая система не выровнена относительно чанков, или если мы пишем сразу на все диски, то кол-во IOPS может изменяться. Во многих случаях операции записи кэшируются в памяти (сервера или дискового контроллера) и уже потом пишутся на диск последовательно.
Любые операции чтения, которые выполняются на дисках, не подвергаются никакому пенальти, поскольку все диски могут использоваться для операций чтения.
Это почему же не подвергаются? Какие полезные данные вы получаете с дисков, хранящие четность в RAID-5 или RAID-6? Или даже более наглядный пример — RAID-4, который использует выделенный диск под хранение четности.
Диалог мог бы выглядеть примерно вот так:
Василич: -И почему я должен один это тащить?
Семён: -Э-ээ… у меня в школе тройка по физкультуре была…
Олег: -Только учтите — шкаф больше, чем на 5 градусов не наклонять!
Живая миграция… А вот смигрировать с хоста на хост (или куда еще) без общего хранилища под силу только Hyper-V — хотя функция действительно важная и полезная, жалко что только у одного гипервизора реализован данный механизм.
Неправда, мигрировать без общего хранилища между хостами умеет VMware Enhanced vMotion, доступный в Essential Plus и выше, и Storage vMotion для этого не нужен.
«У VMware есть технология Fault Tolerance — когда что-то подобное будет в Hyper-V?» — Ответ будет похож на предыдущий, но… Я лично эту технологию считаю кастрированной — судите сами — вы ее включили. Но что вы будете делать с виртуалкой у которой может быть всего 1 процессор и не более 4 Гб ОЗУ?
Неправда, ограничение — 64 ГБ памяти на ВМ.
По Citrix:
Очень грустно за Citrix в данном конкретном случае — у XenServer никаких технологий оптимизации работы с SAN-системами нет.
Это не так. Технология оптимизации работы с хранилищами у Ctirix есть, называется StorageLink.
VXLAN — механизм абстракции и изоляции виртуальной сети с возможностью ее динамического расширения.
У Citrix есть схожий механизм в расширяемом коммутаторе (cross-server private network) основанный на GRE туннелях.
Защита от спуффинга и неавторизованных пакетов — здесь ситуация простая. Бесплатно воспользоваться защитой от нежелательных пакетов и атак можно только в Hyper-V. У Citrix, к сожалению, такого функционала нет
У Citrix есть возможность создавать ACL правила по протоколам и портам.
У Citrix XenServer есть большое преимущество по сравнению с Hyper-V и, теперь уже, vSphere — это возможность запускать ВМ с Linux в paravirtual режиме, что должно положительно сказываться на производительности.
С точки зрения функционала — все гипервизоры примерно одинаковы, но я бы выделил VMware и Hyper-V как 2-х лидеров. Если сравнивать их между собой — то исключительно вопрос денег и функционала, а также вашей ИТ-инфраструктуры — чего у вас больше — Linux или Windows? У VMware все вкусные фичи стоят денег — у Microsoft — нет.
Hyper-V 3.0 неплохой гипервизор, одна проблема — до выхода System Center 2012 SP1 его нельзя рассматривать как серьезное корпоративное решение.
От этого и все эти сравнения с оговорками только про «бесплатный» функционал, только про гипервизоры; пространные размышления — нужны ли вам такие «специфические» вещи, как Storage DRS, Fault Tolerance, SIOC, Network IO Control и прочее, прочее… до тех пор, пока у самих не появится: Guest Numa, Live Storage Migration, Live Migration, Dynamic Memory, 64 vCPU потому что, мол, рынок «созрел», заказчики «просят» и т.п.
Нативная поддержка 4Кб-секторов в виртуальных дисках — достаточно критичная вещь для ресурсоемких приложений.
Приведите, пожалуйста, пример тестов, где диски с 4КБ секторами оказывали большОе влияние на производительность приложений?
Когда сравниваются продукты, важно отмечать не только на заявление о наличии той или иной функции, но и на каком уровне уровне обеспечивается поддержка
Качество обслуживания, поддержка QoS — по сути механизмы оптимизации трафика и гарантии качества канала передачи данных.
Hyper-V обеспечивает ограничение только по bandwidth, в то время как vSphere позволяет ограничивать по Bandwidth, назначать CoS на трафик, делить пропускную способность в долевом отношении (shares). В то же время, на vSphere можно Cisco Nexus 1000v, который обеспечит полнофункциональный QoS, чем Hyper-V пока похвастаться не может.
Однако, все 4 технологии начинаю свою работу только в условиях повышенной нагрузки на ресурсы хост-системы, т.е. по своей манере действия они являются реактивными, нежели проактивными или оптимизирующими.
Правильно ли я понимаю, что этим вы хотите сказать, что Hyper-V начинает свопить память ВМ еще до того, как оперативная память хоста закончится? :-)
ESXi не умеет дедуплицировать такие большие блоки данных — он начинает их разбивать на блоки меньшего размера, 4 Кбайта, а вот уже их он и дедуплицирует — но все эти операции стоят ресурсов и времени — так картина не такая уж однозначная с точки зрения полезности данных технологий.
У вас есть тесты, в которых при использовании больших страниц внутри ВМ наблюдается ощутимо большая производительность или тесты по которым переход ESXi на использование 4 КБ страниц при большой загрузке памяти существенно снижает производительность? Или вы просто делаете некие логические умозаключения? Считаете ли вы, например, что в этом случае своппинг памяти в виде Dymanic Memory гораздо меньше влияет на производительность по сравнению с механизми vSphere, вроде TPS, SSD Host Cache или Memory Compression?
Бесплатно воспользоваться защитой от нежелательных пакетов и атак можно только в Hyper-V. У Citrix, к сожалению, такого функционала нет, а у VMware вам придется докупать решение vShield App либо от сторонних партнеров.
vShield App позволяет создавать ACL правила по различным критериям, включая тип протокола и номер порта, указывать в качестве источника или назначения не только IP адрес, а виртуальную сеть/группу портов, Hyper-V умеет создавать правила только по IP и MAC адресам.
Живая миграция — ее поддерживают все, кроме бесплатного ESXi. Количество одновременных миграций — параметр очень тонкий. У VMware он ограничен технически на уровне гипервизора, а Hyper-V — на уровне здравой логики и физических возможностей инфраструктуры.
Ограничение в четыре одновременные миграции не является техническим, его можно изменить на большее значение, вопрос — надо ли? Вы уверены, что если Hyper-V будет мигрировать, например, восемь ВМ одновременно, то сделает это быстрее, чем vSphere, который будет мигрировать всего по 4-ре? В VMware миграция может осуществлять через несколько сетевых адаптеров. В Hyper-V для этого придется городить огород с nic teaming'ом.
VXLAN… На сегодняшний день только Hyper-V по умолчания поддерживает данный механизм
Неправда, Hyper-V из коробки не поддерживает VXLAN. Возможно, будет поддерживать через Cisco Nexus 1000v. Hyper-V может поддерживать IP address mobility, но никакого отношения к VXLAN это не имеет и работает на базе GRE туннелей или IP Address Rewrite.
Репликация ВМ — решение для катастрофоустойчивого сценария, когда вам необходимо иметь возможность поднять актуальные экземпляры ВМ в другом дата-центре. У VMware для реализации этого решения есть отдельный продукт — Site Recovery Manager (SRM)
У VMware есть vSphere Replication, который сравним с Hyper-V Replica, SRM — это продукт совсем другого уровня. Бесплатность Hyper-V Replica накладывает определенные ограничения, например, отсутствие поддержки защиты Exchange с помощью данного механизма, возможность делать консистентные реплики на уровне приложений не чаще, чем раз в час, необходимость поднимать и тестировать ВМ вручную и т.п.
Правила распределения ВМ — механизм, который позволяет распределять ВМ на кластере так, чтобы они либо никогда не встречались на одном хосте, либо наоборот — никогда не разъезжались между собой.
У Hyper-V Failover Cluster нет явной возможности настроить Affinity правила, чтобы две ВМ работали на одном хосте (только Anti-Affinity). Приходится шаманить с скриптами или Preffered Owner.
Также заметил, что в некоторых тестах vGPU профили с меньшим объемом видеопамяти (K260Q) могут демонстрировать лучшую производительность. Использование пофилей K280Q вообще не очень целесообразно, т.к. можно отдать ядро видеоадаптер напрямую (режим vDGA), единственный плюс vGPU в этом случае — чуть более простая настройка аппаратного ускорения внутри гостевой ОС.
Бенчмарк SPECviewPerf, по-сути, единственный широко применяемый тест, но его результаты сильно зависят от частоты процессора, поэтому не стоит удивляться ситуации, когда на какой-нибудь средненькой рабочей станции Core i5 с 4-я ядрами, результаты будут заметно лучше, чем на сервере с 16-ядерными Xeon с меньшей частотой.
Что касается Windows Server, то их можно использовать в качестве гостевых ОС в VDI вместо Windows 7, но нужно обращать внимание на то, какие функции VDI не поддерживаются в Windows Server.
Согласно спецификации EVO:RAIL конфигурация одного сервера на 2.5" дисках включает в себя 1 x SSD на 400 ГБ и 3 x HDD по 1.2 ТБ, что в сумме на одну коробку дает 1.6 ТБ кэша на SSD и 14.4 ТБ хранилища на HDD. Для максимумов эти цифры умножаются на 4.
Все серверы EVO:RAIL объединяются в один кластер, в котором настроен vSphere High Availability, DRS, VSAN. Миграция ВМ выполняется при помощи vMotion.
Гарантированно — столько, каков показатель Fault to tolerate. При оптимистичном сценарии — в VSAN данные доступны, пока доступно более половины компонентов и хотя бы одна полная копия данных.
Учитывая то что Nutanix показывает выдающиеся параметры производительности, и не имеет лимитов по размеру кластера
Делать неограниченный по размеру кластер — не всегда хорошая идея. Иногда несколько кластеров меньшего размера более оптимальны. Учитывая, что размер кластера VSAN (32 узла) равен размеры кластера HA/DRS, то это небольшое ограничение.
SSD в VSAN — это просто кэш, который крайне неэффективно расходуется.
А можете написать поподробнее — почему неэффективно? В VSAN данные в кэше на чтение хранятся однократно, один объект может быть разбит на несколько компонентов, каждый из которых может хранится в отдельной дисковой группе, а значит, использовать отдельный SSD по кэширование операций чтения.
Это в теории. А на практике, для VSAN / EVO:RAIL бурно сокращают HCL список, ибо у клиентов возникают серьезнейшие проблемы.
Про сокращение HCL — речь об исключении Intel AHCI в финальном релизе VSAN? У вас, насколько я знаю, он тоже не используется.
Этот момент не ясен, поясните. Fault Domain у VSAN засчет встроенности в ядро — не изолирован совершенно.
На текущий момент мне неизвестен ни один баг, который бы приводил из-за этого к отказу ядра, зато известен как минимум один баг с реализацией NFS. kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2076392
-Возможность хранения от 1 до 4 копий объектов (у Nutanix 2 или 3).
-У VSAN кол-во копий, размер резервируемого кэша, thin/thick provisiong задается с помощью политик на уровне ВМ и отдельных виртуальных дисков, у Nutanix — это нужно делать на уровне датасторов ВМ.
-Отсутствие легаси в виде виртуальных апплайнсов, которые отдают датастор по NFS.
-Возможность установки в один сервер до 5-и SSD и до 35 жестких дисков (у Nutanix — в зависимости от модели, но не более 20).
-В целом, более широкий перечень поддерживаемых конфигураций оборудования.
-Возможность ограничения размера fault domain'а в рамках одного хост сервера за счет создания нескольких дисковых групп.
-VSAN входит в состав старших редакций View.
Так что сравнение Windows 3.11 и MacOS 10.10 выглядит несколько натянутым.
Интересует ваше мнение (как официального представителя) — по какие задачи не следует предлагать Nutanix? С физическими серверами — понятно, интересуют другие варианты. С ходу я смог придумать такие:
1) Развертывание Monster VM (64 vCPU, 1 TB RAM) под задачи какой-нибудь большой-большой СУБД или ERP системы. Конфигурация самой старшей ноды (NX-9040), на текущий момент, слабее лимитов гипервизоров.
2) Требование к дешевому дисковому пространство (например, для хранения бекапов или файлопомойки). В NX-8150 установлено 20 x 1 TB дисков, классическая архитектура с какой-нибудь JBOD полкой или просто дешевым массивом позволяет устанавливать более емкие 3.5" диски с большей плотностью размещения.
3) Малый (сверхмалый :-)) бизнес или бранч-офис. У меня нет под рукой прайс-листа Nutanix, но полагаю, что для небольшого бранч-офиса купить 2-3 обычных сервера и выделенный массив или дисковую полку, подключаемую по SAS, выйдет дешевле, чем купить NX-1020.
4) Использование Infiniband и всевозможных ускорителей (NVIDIA Tesla, Intel Xeon Phi).
Что вы думаете по поводу приведенных выше примеров? Возможно что-то еще?
В Microsoft Hyper-V RemoteFX работает с видеокартами обоих производителей.
В VMware vSphere в режиме vDGA могут пробрасываться и видеокарты NVIDIA, и AMD. Для режима vSGA поддерживается крайне небольшой список видеокарт: NVIDIA GRID K1 и K2, а также AMD FirePro S7000, S9000 или W7000.
Что касается Citrix, то для GPU Passthrough, опять же, нет особой разницы, что прокидывать, но в официальном HCL Citrix присутствуют только карты NVIDIA. Для Virtual GPU, действительно, поддерживаются только GRID K1 и K2.
Ежели NetApp делает хранилки для Dell, то почему картинки не может?
Если же сравнивать с гипервизорами первого типа (VMware ESXi, Microsoft Hyper-V, Citrix XenServer), то и тут KVM далеко не самый-самый. У каждого решения есть свои плюсы и минусы.
Эти расчеты актуальны до тех пор, пока записываемый блок данных меньше или равен чанку, из которых состоит raid. Если же блок записываемых данных больше, или, банально, файловая система не выровнена относительно чанков, или если мы пишем сразу на все диски, то кол-во IOPS может изменяться. Во многих случаях операции записи кэшируются в памяти (сервера или дискового контроллера) и уже потом пишутся на диск последовательно.
Это почему же не подвергаются? Какие полезные данные вы получаете с дисков, хранящие четность в RAID-5 или RAID-6? Или даже более наглядный пример — RAID-4, который использует выделенный диск под хранение четности.
Диалог мог бы выглядеть примерно вот так:
Василич: -И почему я должен один это тащить?
Семён: -Э-ээ… у меня в школе тройка по физкультуре была…
Олег: -Только учтите — шкаф больше, чем на 5 градусов не наклонять!
По VMware:
Неправда, мигрировать без общего хранилища между хостами умеет VMware Enhanced vMotion, доступный в Essential Plus и выше, и Storage vMotion для этого не нужен.
Неправда, ограничение — 64 ГБ памяти на ВМ.
По Citrix:
Это не так. Технология оптимизации работы с хранилищами у Ctirix есть, называется StorageLink.
У Citrix есть схожий механизм в расширяемом коммутаторе (cross-server private network) основанный на GRE туннелях.
У Citrix есть возможность создавать ACL правила по протоколам и портам.
У Citrix XenServer есть большое преимущество по сравнению с Hyper-V и, теперь уже, vSphere — это возможность запускать ВМ с Linux в paravirtual режиме, что должно положительно сказываться на производительности.
Hyper-V 3.0 неплохой гипервизор, одна проблема — до выхода System Center 2012 SP1 его нельзя рассматривать как серьезное корпоративное решение.
От этого и все эти сравнения с оговорками только про «бесплатный» функционал, только про гипервизоры; пространные размышления — нужны ли вам такие «специфические» вещи, как Storage DRS, Fault Tolerance, SIOC, Network IO Control и прочее, прочее… до тех пор, пока у самих не появится: Guest Numa, Live Storage Migration, Live Migration, Dynamic Memory, 64 vCPU потому что, мол, рынок «созрел», заказчики «просят» и т.п.
Приведите, пожалуйста, пример тестов, где диски с 4КБ секторами оказывали большОе влияние на производительность приложений?
Когда сравниваются продукты, важно отмечать не только на заявление о наличии той или иной функции, но и на каком уровне уровне обеспечивается поддержка
Hyper-V обеспечивает ограничение только по bandwidth, в то время как vSphere позволяет ограничивать по Bandwidth, назначать CoS на трафик, делить пропускную способность в долевом отношении (shares). В то же время, на vSphere можно Cisco Nexus 1000v, который обеспечит полнофункциональный QoS, чем Hyper-V пока похвастаться не может.
Правильно ли я понимаю, что этим вы хотите сказать, что Hyper-V начинает свопить память ВМ еще до того, как оперативная память хоста закончится? :-)
У вас есть тесты, в которых при использовании больших страниц внутри ВМ наблюдается ощутимо большая производительность или тесты по которым переход ESXi на использование 4 КБ страниц при большой загрузке памяти существенно снижает производительность? Или вы просто делаете некие логические умозаключения? Считаете ли вы, например, что в этом случае своппинг памяти в виде Dymanic Memory гораздо меньше влияет на производительность по сравнению с механизми vSphere, вроде TPS, SSD Host Cache или Memory Compression?
vShield App позволяет создавать ACL правила по различным критериям, включая тип протокола и номер порта, указывать в качестве источника или назначения не только IP адрес, а виртуальную сеть/группу портов, Hyper-V умеет создавать правила только по IP и MAC адресам.
Ограничение в четыре одновременные миграции не является техническим, его можно изменить на большее значение, вопрос — надо ли? Вы уверены, что если Hyper-V будет мигрировать, например, восемь ВМ одновременно, то сделает это быстрее, чем vSphere, который будет мигрировать всего по 4-ре? В VMware миграция может осуществлять через несколько сетевых адаптеров. В Hyper-V для этого придется городить огород с nic teaming'ом.
Неправда, Hyper-V из коробки не поддерживает VXLAN. Возможно, будет поддерживать через Cisco Nexus 1000v. Hyper-V может поддерживать IP address mobility, но никакого отношения к VXLAN это не имеет и работает на базе GRE туннелей или IP Address Rewrite.
У VMware есть vSphere Replication, который сравним с Hyper-V Replica, SRM — это продукт совсем другого уровня. Бесплатность Hyper-V Replica накладывает определенные ограничения, например, отсутствие поддержки защиты Exchange с помощью данного механизма, возможность делать консистентные реплики на уровне приложений не чаще, чем раз в час, необходимость поднимать и тестировать ВМ вручную и т.п.
У Hyper-V Failover Cluster нет явной возможности настроить Affinity правила, чтобы две ВМ работали на одном хосте (только Anti-Affinity). Приходится шаманить с скриптами или Preffered Owner.
А как у LeftHand OS дела обстоят с tier'ингом на уровне блоков?