10 причин перейти к серверной виртуализации с MS Hyper-V, комментарии

Комментарии предполагают некоторую дискуссионность, поэтому хочется отдельным постом ответить на комментарии к предыдущей записи:
10 причин перейти к серверной виртуализации с MS Hyper-V.

Комментарии выделены синим. Текст из предыдущего поста курсивом.:
4) Hyper-V microkernelized hypervisor - типа, гипервизор маленький и удаленький, нет лишнего - лучше безопасность.
В этом пункте проступает прямая аналогия с ESXi. Но, в любом случае, Hyper-V кроме маленького гипервизора требует установки и ядра Win2008. ESXi тоже состоит не только из гипервизора - еще он содержит маленький линукс, но, сдается мне, активней дыры будут искаться(и находиться)в винде


Только вы забыли указать что у МС в гипервизоре размером в 670 кб работает только менеджер памяти и планировщик задач. Все остальные компоненты и ws2008 родительского раздела работают в режиме пониженных привилегий.
А у ESX там полноразмерный Linux в 32 мб. С драйверами устройств и прочим счастьем.
Так что поверхность атаки у Hyper-v в разы меньше.
Поймите меня правильно - я пытаюсь беспристрастно писать о разных решениях. По поводу удачности\неудачности архитектур - рассудит жизнь, мне не хватит знаний. Но с учетом понятной популярности Win2008, и, как следствие, больших усилий по поиску дыр - я склонен полагать, что проблемы с безопасностью будут. это мое_личное_мнение, и аргументирую я его не технически.

Опять же не забывайте что включение драйверов в гипервизор предполагает не только снижение безопасности, но и несовместимость таких драйверов с обычными Linux драйверами. А это значит затрудненную поддержку нового оборудования. У Hyper-v таких проблем нет потому что используются стандартные драйвера от WS2008.
Не думаю, что этот момент принципиален. Список совместимого железа достаточно велик у VMware. Не так?

По поводу найденых дыр посмотрите материалы недавней Black Hat Conference. Эксплоит который может из виртуальной машины разрушить гипервизор ESX или внедрить в него свой rootkit это отличная заявка на первый приз по безопасности. Вот вам и монолитный гипервизор с очень маленьким Linux.

Торвальдс не зря сказал про проблемы монолитного гипервизора:

The fact is, the absolute last place you want to see drivers is in the hypervisor, not only because the added abstraction layer is inevitably a big performance problem, but because hardware and drivers are by definition buggier than "generic" code that can be tested.

Мне тут возразить нечего, опять таки в силу недостаточности знаний. В любом случае, я не считаю чье либо решение лучшим с этой т.зрения. Разные подходы - разные проблемы.



6) Quick Migration - для миграции ВМ между хостами с минимумом простоя.
Ну по поводу отставания QM от VMotion не сказал только ленивый. Например.


С VMotion не все так красиво и радужно как кажется. VMotion работает в пределах одной подсети. При отключении электричества во всем здании или других катастрофических событиях цена такой миграции ноль копеек.
Так, с этим сложно спорить. Если хост с ВМ на нем уже упал, VMotion отдыхает. А что сможет сделать QM? Я правильно понимаю, что QM позиционируется как средство для миграции ВМ с работающего хоста на работающий. Вот тут так и написано:
Quick migration. Enables movement of running virtual machines from one host to other host servers with minimal downtime.
Я неправ? Если прав, то в случае смерти хоста с ВМ, делать Quick migration уже поздно.
А Hyper-v умеет мигрировать машины в географически распределенных кластерах. Вопрос лишь в скорости копирования образа оперативной памяти.
Поясните пожалуйста. Вот у нас есть Сервер1. Видит ЛУН1. На нем лежит файл-диск ВМ1. Мы хотим эту ВМ1 перенести на Сервер2, стоящий далеко. Что происходит по шагам?