Перейти к содержимому

Windows 2008 Hyper-V

Microsoft выпустил встроенный в Win2008 менеджер виртуализации Hyper-V. Этот пост - про мое с ним близкое знакомство

Относительно недавно, выпустил менеджер виртуализации под названием . В этом посте я расскажу про мое с ним близкое знакомство, про мое мнение по поводу данного менеджера, и, на сладкое - установка в виртуальную машину под управлением -VГлавные отличия Hyper-V от других систем виртуализации состоят лишь в трех, но, все же, весьма существенных пунктах:

  1. В Hyper-V нет возможности использовать memory overcommit и memory sharing (такова позиция Майкрософта).
    Минусы данного подхода в том, что Вы не сможете хостить большее количество виртуальных машин, чем у Вас есть . Казалось бы, весьма здравый подход, но, все-таки: например, есть у Вас 4 гигабайта памяти на хосте, в котором запущен Hyper-V. И 4 приложения, которые необходимо виртуализовать, в минимальных требованиях к которым написано что им необходимо минимум 2 гигабайта ОЗУ (ситуация может быть усугублена инсталлятором, проверяющим соотвествие параметров хоста минимальным требованиям приложения). Но, ввиду некоторых обстоятельств (опыт, использование приложения в небольшой группе пользователей, тестовый сервер и так далее) Вы точно знаете, что Вам не нужно такое количество ОЗУ. В случае, если применяется Hyper-V - Вам придется расширить общий объём ОЗУ до минимума в 10 гигабайт (4*2 дял виртуалок, +1 гиг для хоста, + 1 гиг для Hyper-V).
    А с memory sharing ситуация еще интереснее - уточню, что в нашем примере мы хостим 4 виртуальные машины под управлением Windows 2008 Webserver, что автоматически означает, что мы имеем в каждой виртуальной машине порядка 500 мегабайт абсолютно идентичных данных в памяти. Таким образом, наличие memory sharing позволяет в нашем примере сэкономить 1.5 гигабайта весьма недешовой оперативной памяти. А если увеличить количество хостов - то размер сэкономленой ОЗУ будет лишь расти.
    Прекрасный пример приводит Gabes в своем блоге - http://www.gabesvirtualworld.com/hyper-v-not-in-my-datacenter-part-2-guest-os-and-memory-overcommit/
  2. Так называемый SnapshotHell.
    В Hyper-V, как и в прочих менеждерах виртуализации, существует механизм создания точек восстановления гостевой ОС при помощи так называемых снепшотов.
    Идея весьма хороша, на первый взгляд - вы запланировали важное обновление, но не до конца уверены в его последствиях/стабильности. Делаем снепшот, обновляемся, тестируем. При неудовлетворительных результатах - откатываемся (тут проблем почти нет), при положительном результате - продолжаем работу. И вот как раз тут, при положительном результате нас поджидает весьма неожиданная ловушка - даже если снепшот удален из консоли Hyper-V, наша виртуальная машина продолжает писать данные в avhd файл, сгенерированный при создании снепшота, до тех пор, пока виртуальная машина не будет выключена на время, необходимое для объединения снепшота с основным диском.
    Тут необходимо небольшое пояснение: в отличии от VHD файла, содержащего виртуальный диск, и ограниченного в размере настройками заданными при создании ВМ (виртуальной машины), AVHD файл содержит в себе все дисковые транзакции за время с создании снепшота до момента объединения AVHD и VHD файла, которое может состояться только если ВМ находиться в отключенном состоянии.
    Вот пример из моей практики общения с Hyper-V: была создана ВМ как хост для сервера баз данных. После установки MSSQL Server 2008 R2, необходимых обновлений и переноса баз данных на новый хост, пришел новый патч для MSSQL сервера, и, в целях собственной безопасности, я сделал снепшот, применил патч, убедился что все в порядке, удалил снепшот и забыл про это. Как же я ошибался! Через месяц, инспектируя хостовую машину, я обнаружил, что место на винчестере стремиться к нулю. Начал разбираться, и обнаружил, что AVHD файл сожрал почти все свободное место, и занимает 1 терабайт (для ВМ баз данных размер винчестера был определен в 600 гигабайт). Сведение VHD и AVHD файлов (их было несколько) заняло около 60 часов (все это время хост с базами данных был недоступен), и, тут выявилась еще одна проблема - итоговый размер VHD файла (файл с виртуальным жестким диском ВМ) равен стартовому размеру VHD файла (до снепшота) плюс сумма размеров AVHD файлов (в моем случае - 1.6 терабайта). Компактификация VHD файла заняла еще 4 часа. Итого: 64 часа простоя и куча сожженных нервов.
    Таким образом, на мой взгляд, дешевле бекапить весь VHD файл, чем использовать такую заманчивую функцию снепшотов.
    Вот, интересный пост на данную тему- http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/03fc01f5-5428-4f4f-b86a-98ead7d72740/
  3. Стоимость владения. Тут Hyper-V выгодно отличается от своих конкурентов, в том, что будучи продуктом Майкрософт, позволяет значительно снизить стоимость установки дополнительных виртуальных машин. Если взять к примеру, ESX(i), то там, для каждой ВМ Вам нужно приобретать лицензию у Майкрософта. В случае с Hyper-V, ценовая модель такова: приобретая 2008 Enterprise за ~$1.500 (или 2008 R2 Enterprise), Вы получает 4 дополнительных виртуальных ключа для любых редакций Windows 2008 Server (и R2 тоже), при условии, что хост будет иметь лишь одну роль - Hyper-V. Если Enterprise хост будет выполнять еще какие либо обязанности, то на нем можно развернуть еще 3 Windows-хоста (и неограниченное количество других ОС). Приобретая Datacenter за ~$3.000, Вы можете хостить неорганиченное количество виртуальных машин.

Вот, собственно говоря все, что я хотел рассказать про Hyper-V.
И, обещанное сладкое - установка Debian'a в виртуальную машину под управлением гипервизора Hyper-V.
Собственно говоря, установка проходит как обычно, на реальную машину, за исключением нескольких проблем: в отличии от поддерживаемых дистрибутивов , Debian не найдет стандартную сетевую карту, поэтому первоначальную установку придется проводить в включенным Legacy адаптером. И вторая загвоздка - если Вам нужно более чем 127 гигабайт на винчестере, то придется хитрить - на IDE создаем небольшой винчестер для /root, /swap и /tmp разделов, а после завершения установки и компиляции собственного ядра для корректной поддержки синтетических устройств - подключаем SCSI винчестер нужного размера и читаем далее.

Компиляция ядра с поддержкой синтетических устройств Hyper-V.
Чтобы не ощущать себя вором, и дабы было понятно, что моей работы в это описание почти не вложено - вот, прекрасный пост, как сделать нужное ядро: http://blogs.technet.com/b/abeshkov/archive/2011/03/17/hyperv_5f00_debian.aspx

Вот собственно говоря и все.

З.Ы. Хочу попросить у читателей моего блога - если у Вас есть ответ на вопрос, заданный тут http://serverfault.com/questions/324318/debian-fsck-fails-at-boot-but-successful-in-maintenance-mode-or-in-regular-mo - запостите его в комментариях, или же на ServerFault. Это единственное, что меня сейчас мучает! Спасибо за внимание.