Установка и настройка hyper-v server для тех, кто впервые его видит
Вступление
Сегодня я расскажу о том, как установить и настроить гипервизор hyper-v server от компании Microsoft, а так же о некоторых подводных камнях и способах их избежать.
Поводом для написания этот статьи стал материал данного поста. Этот пост подходит больше как шпаргалка, если вы уже работали с данным гипервизором. Новичку же придется столкнуться с кучей нюансов и перекопать немало форумов, в поисках ответов на нестандартные вопросы.
Эта писалась из расчета — как бы я сам хотел видеть подобный мануал по установке. Для новичков я постарался максимально подробно изложить все действия и их смысл, дабы у них была возможность начать экспериментировать и придумывать что-то свое. Для более подкованных — я разделил статью на логические блоки и подблоки, чтобы можно было быстро найти необходимую информацию.
Под катом много текста и скриншотов
Описание
MS hyper-v server представляет собой урезанную версию MS server 2008 R2 в режиме Core (т.е. фактически, графический интерфейс отсутствует) с установленной ролью hyper-v и ничего более. Согласно википедии hyper-v server распространяется бесплатно, что вкупе с удобным управлением и интеграцией с продуктами от MS, делает его очень привлекательным гипервизором. Кроме того он имеет достаточно высокие показатели по производительности, а значит ресурсы хостовой машины будут расходоваться на работу нужных нам сервисов.
Установка
Перед началом установки необходимо убедиться, что ваш процессор поддерживает технологии аппаратной виртуализации Intel VT-x или AMD-V.
Для начала необходимо скачать дистрибутив hyper-v server 2008 R2 с сайта Microsoft (регистрироваться не нужно). Далее нарезать образ на DVD-диск или сделать установочную флешку.
Вставляем диск/флешку и загружаемся с нее.
Hyper-v server — выбор языка мастера установки
Окно установки предлагает нам выбрать язык операционной системы. Выбираем английский, далее объясню, почему именно его.
Hyper-v server — выбор языка ОС и раскладки клавиатуры
Язык мы выбрали английский, а формат времени лучше выбрать русский, чтобы потом не мучиться с настройкой в командной строке.
Далее жмем кнопку «Install now». Читаем и принимаем с лицензионное соглашение.
Hyper-v server — выбор типа установки
Выбираем полную установку (Custom).
Hyper-v server — настройка параметров жесткого диска
На этом этапе мастер предлагает настроить параметры разделов жесткого диска. Лучше всего создать 2 логических диска. Первый — для установки самого гипервизора, ему хватит 15 Гб. Второй для хранения контейнеров виртуальных машин (ВМ). Таким образом, будет намного удобнее осуществлять управление, импорт и миграцию ВМ.
Жмем «Next» и уходим пить чай. В процессе установки компьютер несколько раз перезагрузится.
Настройка
Базовая настройка и удаленный доступ
После перезагрузки hyper-v server предложит нам установить пароль администратора. Так как по-умолчанию в групповой политике ms windows 2008 server r2 стоит требование к сложности пароля, придется придумать пароль длинной от 6 символов, обязательно содержащий заглавную букву и спецсимвол или цифру (например «Password1»).
Как вы можете заметить ниже на скриншотах консоль управления у меня на русском языке, хотя при установке был выбран английский язык, скорее всего это из того, что с официального сайта Microsoft я скачал русский дистрибутив. На работу и настройку сервера это негативным образом не повлияет. Если же у вас консоль на английском — можно делать по аналогии, все настройки будет легко понять.
Hyper-v server — интерфейс управления
После загрузки рабочего окружения, ОС предлагает нам 2 консоли управления. Стандартная командная консоль cmd и консоль с предустановленными опциями. Первым делом нам необходимо задать статический ip-адрес и настроить удаленное управление сервером. В консоли управления выбираем пункт 8.
Hyper-v server — сетевые адаптеры
В списке будут перечислены сетевые адаптеры. Выбираем нужный и вписываем его индекс. Далее выбираем «1 — установить ip-адрес сетевого адаптера». Вписываем «S» — что означает статический ip-адрес. Для примера зададим параметры:
ip-адрес — 192.168.1.100
маска подсети — 255.255.255.0
шлюз по-умолчанию 192.168.1.1
После применения параметров, мы вернемся в подменю, где будут перечисленные ранее внесенные настройки. Если все верно возвращаемся в главное меню.
Теперь настроим удаленный доступ. Выбираем пункт 7, далее включаем удаленный рабочий стол, вписав английскую «E». На вопрос об ограничении подключений от rdp-клиентов старых версий, выбираем «2» — подключаться от любых клиентов.
В главном меню выбираем пункт 9, и задаем актуальную дату и время на сервере.
Сетевое имя сервера и рабочая группа
Теперь настроим рабочую группу. Для работы hyper-v server, я не стал включать его в домен, что несколько усложняет настройку, но для экспериментов это идеальный вариант. Во время тестов и проверки различных конфигураций, лучше изолировать тестовые машины от целевой сети.
Выбираем пункт 1, затем «присоединиться к рабочей группе» вписав «W». Далее задаем название рабочей группы, например «test». Очень важно, чтобы имя рабочей группы на hyper-v server и ПК, с которого мы планируем им управлять, совпадали. После этого мы возвращаемся в главное меню.
Желательно задать сетевое имя сервера, выбираем пункт 2 и вписываем имя, например «hyper-srv». Для применения параметров необходимо перезагрузиться, соглашаемся с предложением ОС.
Далее все настройки (такие как имя компьютера, рабочей группы, пользователи, ip-адрес и т.д.) я буду приводить те, что описывал в процессе установки. Если вы задавали свои параметры, не забывайте использовать именно их.
Итак, мы подключились, теперь необходимо настроить дополнительные параметры удаленного управления. Заходим в пункт 4. Теперь по порядку выбираем подпункты 1, 2 и дожидаемся окончания настройки. После завершения, ОС опять попросит перезагрузиться. По завершению этих настроек мы сможем подключаться к серверу с помощь консоли mmc и диспетчера сервера hyper-v из пакета Remote Server Administration Tools (RSAT). Подробнее об этом я опишу далее по тексту.
Установка RSAT и диспетчера hyper-v
Для комфортного удаленного управления сервером (создание/удаление/импорт/настройка ВМ, добавление/удаление оборудования, управления пользователями/групповыми политиками и т.п.) нам необходимо установить RSAT на наш ПК. Устанавливать будем на windows 7. Первым делом скачаем его отсюда. В этом пакете нам нужен компонент “Диспетчер hyper-v” для консоли mmc — это собственно основной инструмент управления будущими ВМ.
Последующие настройки будет необходимо производить как на сервере (для краткости СРВ) так и на нашем управляющем ПК (УК).
Настраиваем пользователей
Для настройки пользователей и групп безопасности есть замечательная утилита “HVRemote”, написанная одним из сотрудников Microsoft.
Скачиваем утилиту и копируем файл «HVremote.wsf» на сервер. Помните в самом начале, я писал, что нужно выбрать английский язык для ОС? Так вот для корректной работы скрипта «HVremote.wsf» необходимо, чтобы группы безопасности и пользователи именовались на английском языке.
Небольшое отступление: как я писал раньше — в hyper-v server отсутствует графический интерфейс. Это не совсем так, Microsoft просто вырезала по-максимому все, что связанно с Explorer, но это не мешает нам запускать приложения имеющие графические окна. Для примера можно скопировать на диск сервера программу «total commander» и запустить ее из консоли.
Hyper-v server — запуск приложений
Hyper-v server — выполнение скрипта
Hyper-v server — диспетчер управления ВМ
Вот собственно и все, мы успешно установили и настроили наш hyper-v server. Теперь можно смело разворачивать виртуальные машины и различные сервисы.
Это моя первая статья на хабре, поэтому жду советов и конструктивной критики
Nikolay Alekseyev’s blog
Нашел полезные статейки по работе с HV. Автор: Алексей Кибкало
Делегирование прав на Hyper-V
По умолчанию Hyper-V разрешает создание и управление виртуальными машинами только администраторам. Сегодня мы поговорим о том, как делегировать эти права пользователям, не обладающими правами администратора сервера.
Hyper-V используют новую модель авторизации пользователей — Authorization Management Framework, которая позволяет гибко настроить права пользователей на виртуальные машины. Модель очень хорошо продумана и имеет ряд интересных моментов, которые я обязательно как-нибудь затрону. Сейчас же мне придется сообщить некую вводную информацию про эту модель, чтобы затем показать настройки делегирования. Итак, термины:
Операция (Operation)
Основной кирпичик модели авторизации — представляет собой действие, которое пользователь может произвести. Примерами операций модели являются op_Create_VM, позволяющая создать виртуальную машину и op_Start_VM, соответственно, запускающая виртуальную машину.
Задача (Task)
Задача — это группа операций, требуемых для выполнения некоторых действий. По умолчанию мы не создаем никаких заданий, но если бы мы могли создать задачу control_VM, то нам бы потребовалось добавить в эту группу операции по запуску (op_Start_VM), остановке (op_Stop_VM), приостановке (op_Pause_VM) и перезапуску (op_Restart_VM) для выполнения необходимых в задаче действий.
Роль (Role)
Роль определяет должность, круг задач или зону ответственности для пользователя. Например, может потребоваться роль Virtual_Network_Admin. Эта роль будет иметь права на все операции и задачи, связанные с виртуальными сетями. При необходимости эту роль можно будет назначать пользователям.
Область (Scope)
Область позволяет вам указать, какие объекты управляются конкретными ролями. Если у вас есть система, и вы хотели бы быть дать пользователю административный доступ к некому набору виртуальных машин в ней, вам потребуется создать область, содержащую эти конкретные виртуальные машины, а затем применить ваши настройки к данной области.
Область по умолчанию (Default Scope)
Область по умолчанию присваивается виртуальным машинам, для которых явно не задана другая область.
Hyper-V может хранить настройки модели авторизации в Active Directory или в локальном файле в формате XML. По умолчанию после установки роли Hyper-V настройки хранятся в файле, который находится по адресу: %programdata%MicrosoftWindowsHyper-VInitialStore.xml. Для того, чтобы изменить настройки, вам потребуется:
На этом ваша задача выполнена. Пользователь может полностью контролировать Hyper-V, не являясь администратором на этом сервере. Делегирование гранулярных прав на конкретные виртуальные машины осуществляется абсолютно таким же образом.
Нaстройка удаленного доступа к Hyper-V
Мы только что рассмотрели, как делегировать пользователю права на управление Hyper-V. Но этими правами пользователь сможет воспользоваться, только работая на сервере локально.
Для того, чтобы управлять гипервизором с другого компьютера, пользователю, который не является администратором, потребуется выполнить ряд настроек — как на стороне сервера, так и на стороне клиента.
Описанные в этой статье шаги применимы к версии RC0 гипервизора Hyper-V и RC0 версии клиентской утилиты управления Hyper-V Manager для Vista SP1 (x86 и x64).
Итак, на сервере следует выполнить следующие шаги:
netsh advfirewall firewall set rule group=»windows management instrumentation (wmi)» new enable=yes
Внимание: в различных локализованных ОС встроенные правила брандмауэера могут назваться по-разному. Необходимо указать название правила именно так, как оно выглядит в инструментах управления Windows Firewall. Например, в русской версии Windows Server 2008 приведенная выше строка будет выглядеть так:
netsh advfirewall firewall set rule group=»Инструментарий управления Windows (WMI — входящий трафик)» new enable=yes
т.е. достаточно этих команд в командной строке (с правами администратора):
net start winmgmt
net start vmms
net start vhdsvc
net start nvspwmi
Внимание: если сервер с установленной ролью Hyper-V, которым вы хотите управлять удаленно, используя локальную запись с правами администратора, не входит в домен, и при этом на сервере включен User Account Control (UAC), то имейте в виду следующее. По умолчанию к локальным учетным записям при неинтерактивном (в том числе сетевом) доступе применяется UAC Filtering. То есть, даже если вы являетесь администратором сервера, при попытке удалённого подключения UAC предоставит вам права стандартного пользователя. Поэтому в таком случае вам потребуется напрямую предоставить пользователю права на Hyper-V способом, описанным в предыдущей статье.
Настройки клиентского компьютера
Итак, сервер мы настроили. Теперь ряд настроек потребуется выполнить и на клиентском ПК с Vista SP1.
netsh advfirewall firewall set rule group=»windows management instrumentation (wmi)» new enable=yes
В русской версии Windows Vista эта же команда выглядит следующим образом:
netsh advfirewall firewall set rule group=»Инструментарий управления Windows (WMI — входящий трафик)» new enable=yes
А на системах с ОС, предшествующими Windows Vista (Windows XP / 2003), для этого служит команда
netsh firewall set service RemoteAdmin enable
netsh firewall add allowedprogram program=%windir%system32wbemunsecapp.exe name=UNSECAPP
netsh firewall add allowedprogram program=%windir%system32mmc.exe name=»Microsoft Management Console»
После выполнения всех описанных действий вы, наконец, получите возможность удаленно подключаться к серверу и управлять ролью Hyper-V.
Архитектура Hyper-V: Глубокое погружение
Что же такое – Hyper-V?
Hyper-V – это одна из технологий виртуализации серверов, позволяющая запускать на одном физическом сервере множество виртуальных ОС. Эти ОС именуются «гостевыми», а ОС, установленная на физическом сервере – «хостовой». Каждая гостевая операционная система запускается в своем изолированном окружении, и «думает», что работает на отдельном компьютере. О существовании других гостевых ОС и хостовой ОС они «не знают».
Эти изолированные окружения именуются «виртуальными машинами» (или сокращенно — ВМ). Виртуальные машины реализуются программно, и предоставляют гостевой ОС и приложениям доступ к аппаратным ресурсам сервера посредством гипервизора и виртуальных устройств. Как уже было сказано, гостевая ОС ведет себя так, как будто полностью контролирует физический сервер, и не имеет представления о существовании других виртуальных машин. Так же эти виртуальные окружения могут именоваться «партициями» (не путать с разделами на жестких дисках).
Впервые появившись в составе Windows Server 2008, ныне Hyper-V существует в виде самостоятельного продукта Hyper-V Server (де-факто являющегося сильно урезанной Windows Server 2008), и в новой версии – R2 – вышедшего на рынок систем виртуализации Enterprise-класса. Версия R2 поддерживает некоторые новые функции, и речь в статье пойдет именно об этой версии.
Гипервизор
Термин «гипервизор» уходит корнями в 1972 год, когда компания IBM реализовала виртуализацию в своих мэйнфреймах System/370. Это стало прорывом в ИТ, поскольку позволило обойти архитектурные ограничения и высокую цену использования мэйнфреймов.
Гипервизор – это платформа виртуализации, позволяющая запускать на одном физическом компьютере несколько операционных систем. Именно гипервизор предоставляет изолированное окружение для каждой виртуальной машины, и именно он предоставляет гостевым ОС доступ к аппаратному обеспечению компьютера.
Гипервизоры можно разделить на два типа по способу запуска (на «голом железе» или внутри ОС) и на два типа по архитектуре (монолитная и микроядерная).
Гипервизор 1 рода
Гипервизор 1 типа запускается непосредственно на физическом «железе» и управляет им самостоятельно. Гостевые ОС, запущенные внутри виртуальных машин, располагаются уровнем выше, как показано на рис.1.
Рис.1 Гипервизор 1 рода запускается на «голом железе».
Гипервизор 2 рода
В отличие от 1 рода, гипервизор 2 рода запускается внутри хостовой ОС (см. рис.2).
Рис.2 Гипервизор 2 рода запускается внутри гостевых ОС
Виртуальные машины при этом запускаются в пользовательском пространстве хостовой ОС, что не самым лучшим образом сказывается на производительности.
Примерами гипервизоров 2 рода служат MS Virtual Server и VMware Server, а так же продукты десктопной виртуализации – MS VirtualPC и VMware Workstation.
Монолитный гипервизор
Гипервизоры монолитной архитектуры включают драйверы аппаратных устройств в свой код (см. рис. 3).
Рис. 3. Монолитная архитектура
Микроядерная архитектура
При микроядерной архитектуре драйверы устройств работают внутри хостовой ОС.
Хостовая ОС в этом случае запускается в таком же виртуальном окружении, как и все ВМ, и именуется «родительской партицией». Все остальные окружения, соответственно – «дочерние». Единственная разница между родительской и дочерними партициями состоит в том, что только родительская партиция имеет непосредственный доступ к оборудованию сервера. Выделением памяти же и планировкой процессорного времени занимается сам гипервизор.
Рис. 4. Микроядерная архитектура
Архитектура Hyper-V
На рис.5 показаны основные элементы архитектуры Hyper-V.
Рис.5 Архитектура Hyper-V
Как видно из рисунка, гипервизор работает на следующем уровне после железа – что характерно для гипервизоров 1 рода. Уровнем выше гипервизора работают родительская и дочерние партиции. Партиции в данном случае – это области изоляции, внутри которых работают операционные системы. Не нужно путать их, к примеру, с разделами на жестком диске. В родительской партиции запускается хостовая ОС (Windows Server 2008 R2) и стек виртуализации. Так же именно из родительской партиции происходит управление внешними устройствами, а так же дочерними партициями. Дочерние же партиции, как легко догадаться – создаются из родительской партиции и предназначены для запуска гостевых ОС. Все партиции связаны с гипервизором через интерфейс гипервызовов, предоставляющий операционным системам специальный API. Если кого-то из разработчиков интересуют подробности API гипервызовов — информация имеется в MSDN.
Родительская партиция
Рис.6 Компоненты родительской партиции Hyper-V
Стек виртуализации
Рабочий процесс виртуальной машины (VMWP)
Для управления виртуальной машиной из родительской партиции запускается особый процесс – рабочий процесс виртуальной машины (VMWP). Процесс этот работает на уровне пользователя. Для каждой запущенной виртуальной машины служба VMMS запускает отдельный рабочий процесс. Это позволяет изолировать виртуальные машины друг от друга. Для повышения безопасности, рабочие процессы запускаются под встроенным пользовательским аккаунтом Network Service.
Процесс VMWP используется для управления соответствующей виртуальной машиной. В его задачи входит:
Создание, конфигурация и запуск виртуальной машины
Пауза и продолжение работы (Pause/Resume)
Сохранение и восстановление состояния (Save/Restore State)
Создание моментальных снимков (снапшотов)
Кроме того, именно рабочий процесс эмулирует виртуальную материнскую плату (VMB), которая используется для предоставления памяти гостевой ОС, управления прерываниями и виртуальными устройствами.
Виртуальные устройства
Драйвер виртуальной инфраструктуры (VID)
Драйвер виртуальной инфраструктуры (vid.sys) работает на уровне ядра и осуществляет управление партициями, виртуальными процессорами и памятью. Так же этот драйвер является промежуточным звеном между гипервизором и компонентами стека виртуализации уровня пользователя.
Библиотека интерфейса гипервизора
Библиотека интерфейса гипервизора (WinHv.sys) – это DLL уровня ядра, которая загружается как в хостовой, так и в гостевых ОС, при условии установки компонент интеграции. Эта библиотека предоставляет интерфейс гипервызовов, использующийся для взаимодействия ОС и гипервизора.
Провайдеры служб виртуализации (VSP)
Провайдеры служб виртуализации работают в родительской партиции и предоставляют гостевым ОС доступ к аппаратным устройствам через клиент служб виртуализации (VSC). Связь между VSP и VSC осуществляется через виртуальную шину VMBus.
Шина виртуальных машин (VMBus)
Назначение VMBus состоит в предоставлении высокоскоростного доступа между родительской и дочерними партициями, в то время как остальные способы доступа значительно медленнее из-за высоких накладных расходах при эмуляции устройств.
Если гостевая ОС не поддерживает работу интеграционных компонент – приходится использовать эмуляцию устройств. Это означает, что гипервизору приходится перехватывать вызовы гостевых ОС и перенаправлять их к эмулируемым устройствам, которые, напоминаю, эмулируются рабочим процессом виртуальной машины. Поскольку рабочий процесс запускается в пространстве пользователя, использование эмулируемых устройств приводит к значительному снижению производительности по сравнению с использованием VMBus. Именно поэтому рекомендуется устанавливать компоненты интеграции сразу же после установки гостевой ОС.
Как уже было сказано, при использовании VMBus взаимодействие между хостовой и гостевой ОС происходит по клиент-серверной модели. В родительской партиции запущены провайдеры служб виртуализации (VSP), которые являются серверной частью, а в дочерних партициях – клиентская часть – VSC. VSC перенаправляет запросы гостевой ОС через VMBus к VSP в родительской партиции, а сам VSP переадресовывает запрос драйверу устройства. Этот процесс взаимодействия абсолютно прозрачен для гостевой ОС.
Дочерние партиции
Вернемся к нашему рисунку с архитектурой Hyper-V, только немного сократим его, поскольку нас интересуют лишь дочерние партиции.
Рис. 7 Дочерние партиции
ОС Windows с установленными компонентами интеграции
ОС не из семейства Windows, но поддерживающая компоненты интеграции
Существуют так же ОС, не относящиеся к семейству Windows, но поддерживающие компоненты интеграции.На данный момент – это только SUSE Linux Enterprise Server и Red Hat Enterprise Linux. Такие ОС при установке компонент интеграции используют VSC сторонних разработчиков для взаимодействия с VSC по VMBus и доступа к оборудованию. Компоненты интеграции для Linux разработаны компанией Microsoft совместно с Citrix и доступны для загрузки в Microsoft Download Center. Поскольку компоненты интеграции для Linux были выпущены под лицензией GPL v2, ведутся работы по интеграции их в ядро Linux через Linux Driver Project, что позволит значительно расширить список поддерживаемых гостевых ОС.
Вместо заключения
На этом я, пожалуй, закончу свою вторую статью, посвященную архитектуре Hyper-V. Предыдущая статья вызвала у некоторых читателей вопросы, и надеюсь, что теперь я на них ответил.
Надеюсь, что чтение не было слишком скучным. Я достаточно часто использовал «академический язык», но это было необходимо, поскольку тематика статьи предполагает очень большой объем теории и практически нуль целых нуль десятых практики.
Выражаю огромную благодарность Mitch Tulloch и Microsoft Virtualization Team. На основе их книги Understanding Microsoft Virtualization Solutions и была подготовлена статья.