Версия hyper v в windows server 2012 r2

Как на хосте виртуализации Hyper-V определить версию гипервизора и версию компонент интеграции ВМ

$fpath = "c:windowssystem32vmms.exe"
[System.Diagnostics.FileVersionInfo]::GetVersionInfo($fpath) | Format-List -property *

Get-VM | Format-Table Name, IntegrationServicesVersion

Одним из главных нововведений в гипервизоре Windows Server 2012 R2 – возможность создавать виртуальные машины второго поколения (Generation 2). Какова же цель разработки второго поколения виртуальных машин Hyper-V, в чем их преимущества и в каких случаях предпочтительно их использовать? В этой статье мы попробуем ответить на все эти вопросы.

В Hyper-V на Windows Server 2012 R2 теперь поддерживаются два поколения виртуальных машин: поколение 1 (Generation 1) и поколение 2 (Generation 2). Виртуальные машины первого поколения (Generation 1) являлись единственным типом виртуальных машин, доступных в предыдущих версиях Hyper-V. В Hyper-V на базе Windows Server 2012 R2 при создании новой виртуальной машины теперь можно указать к какому поколению будет относиться создаваемая виртуальная машина.

Исторические предпосылки разработки второго поколения виртуальных машин

Новое поколение виртуальных машин отличается от предыдущего одним главным принципом – оно разработано специально для оптимизации работы ОС исключительно (и только) в виртуальном окружении Hyper-V. Поколение виртуальной машины определяет набор виртуального «железа» и функционал виртуальной машины. И если предыдущее поколение содержало в себе эволюционные анахронизмы, вытекающие из изначально «физической» архитектуры компьютеров, то виртуальные машины Gen 2 избавлены от этой необходимости, что дает ряд преимуществ.

Главная задача при создании любой виртуальной машины – создание надежной программной эмуляции физического оборудования, которое изначально проектировалось и разрабатывалось без учета возможностей виртуализации. Со временем в архитектуру ОС и аппаратного обеспечения компьютеров вносилось все больше и больше изменений. В результате разработчикам виртуальных платформ для того, чтобы запустить ОС в среде виртуализации, приходилось прибегать к эмуляции различного (в том числе морально устаревшего) оборудования: это BIOS, стандартные порты ввода-вывода (COM, LPT, PS/2), IDE-контроллеры, контроллеры флоппи дисков, контроллеры прерываний, мосты PCI-to-ISA и многое другое.

Эмуляция различного оборудования приводит к увеличению накладных расходов процессорного времени, необходимости поддержки довольного сложного кода и, как следствие этого факта, повышенной поверхности для атак злоумышленников.

Современные ОС, которые проектируются с учетом возможностей работы в виртуальной среде, и уже на этапе загрузки могут понять, что работают внутри ВМ, и не ожидать появления контроллера прерываний или чипсета определенного типа, а напрямую общаться с гипервизором через шину VMBus. Основываясь на этих концепциях, Microsoft решила рискнуть и отказаться от необходимости эмуляции унаследованных устройств и создать для эмуляции оборудования новую платформу с минимальным набором компонентов.

Вот каким образом могут выглядеть списки эмулируемых устройств в Device Manager на ВМ Hyper-V:

1 поколения виртуальных машин Hyper-V:

2 поколения виртуальных машин Hyper-V:

Возможности виртуальных машин Hyper-V второго поколения

Какие же базовые изменения внесены в виртуальные машины Hyper-V Generation 2:

Совет. За данный функционал отвечает опция Enhanced Session Mode в настройках виртуальной машины Hyper-V.

За счет отказа от эмуляции устаревших типов оборудования существенно увеличилась скорость загрузки виртуальной машины и уменьшилось время на установку гостевой ОС. В различных тестах разница в скорости загрузки и развертывания ВМ 1 и 2 поколения достигает 20% и 50% соответственно, что особенно интересно в различных VDI сценариях.

Примечание. В процесс работы ВМ повышение скорости работы виртуальной машины малозаметно, т.к. интеграционные компоненты Hyper-V позволяют виртуальной машины работать на максимально эффективном уровне.

Требования и ограничения виртуальных машин 2 поколения

В качестве гостевых ОС в виртуальных машинах Hyper-V второго поколения поддерживаются:

• Windows Server 2012
• Windows Server 2012 R2
• Windows 8 x64
• Windows 8.1 x64

Судя по всему данное ограничение связано с тем, что именно эти версии ОС поддерживают спецификацию UEFI 2.3.1 с Secure Boot.

Важно. После создания виртуальной машины сменить поколение напрямую невозможно, что не удивительно, т.к. в одном случае используется BIOS, а в другом – UEFI (однако существуют косвенные методы миграции с помощью сторонних утилит или конвертацию V2V).

2-ое поколение виртуальных машин Hyper-V в Windows Server 2012 R2 обеспечивает прирост производительности виртуальных машин, особенно на этапах установки и загрузки, обладает повышенной безопасностью, работает на UEFI и освобождено от необходимости поддержки эмуляции устаревшего оборудования.

За время паузы всего в один год, что соответствует девятимесячному циклу разработки, между выходами систем Windows Server 2012 и Windows Server 2012 R2, компании Microsoft пришлось принимать решение: стоит ли внести небольшие изменения по всему спектру механизмов Windows Server или лучше сосредоточиться на ключевых сценариях и внести значительные изменения в технологии, связанные с этими сценариями? К счастью, компания пошла по второму пути. Одним из главных направлений работы стало «облако». В результате гипервизор Hyper-V в системе Windows Server 2012 R2 может похвастаться значительными улучшениями и новыми возможностями.

Хотя масштабируемость гипервизора Hyper-V не обуславливала изменений при выпуске версии Windows Server 2012 R2 (см. врезку «Масштабируемость в числах»), другие направления выиграли от внесенных улучшений. К таким направлениям можно отнести основной формат виртуальных машин Hyper-V, активацию и подключение, виртуальное хранилище и сетевое взаимодействие, мобильность и репликацию, а также новые возможности, связанные с системами Linux. Данная статья посвящена основным улучшениям, а также изменениям в технологиях мобильности и репликации. Об остальных возможностях я расскажу во второй статье.

Формат виртуальных машин второго поколения

Основная архитектура виртуальных машин Hyper-V не претерпела существенных изменений с момента появления в системе Windows Server 2008. Эта архитектура основывалась на том, что операционные системы виртуальных машин работали в «информационном вакууме». Для операционных систем не существовало понятий виртуализации или виртуализованных устройств. А, следовательно, для их функционирования требовался определенный набор эмулированных устройств.

В гостевых системах, работающих на виртуальных машинах, можно было установить службы интеграции Hyper-V, чтобы дать операционным системам возможность определять собственные виртуальные устройства (например, синтетические сетевые адаптеры и контроллеры SCSI) и повысить производительность. Эти службы интеграции со временем стали частью основных операционных систем, причем не только из линейки Windows. Службы интеграции Hyper-V на сегодня также являются ключевым элементом в распространении систем Linux. Теперь, когда современные операционные системы изначально готовы к виртуализации, первоначальный принцип, заложенный в основу формата виртуальных машин, уже не работает: большинство эмулированных устройств теперь не нужны. Перед вами виртуальные машины второго поколения (Generation 2).

Новое поколение виртуальных машин предназначено для современных операционных систем. Новый формат убирает все эмулируемые устройства, необходимые для «изолированных» операционных систем. В списке потерь значатся эмулируемые под интерфейс PS/2 мышь и клавиатура, контроллер IDE (полностью), устаревший эмулируемый сетевой адаптер Intel, приводы гибких дисков и порты LPT, а также многие системные устройства, такие как мосты PCI-to-ISE и Pentium II Processor-to-PCI. Взамен остается упрощенная виртуальная машина, которая поддерживает загрузку с контроллеров SCSI или с помощью окружения Preboot Execution Environment (PXE) через синтетический (стандартный) сетевой адаптер. Кроме того, виртуальные машины второго поколения позволяют динамически менять размер загрузочного диска. На экране 1 показаны отличия содержимого диспетчера Device Manager у виртуальных машин первого и второго поколения.

Экран 1. Содержимое диспетчера Device Manager для виртуальных машин первого и второго поколения

Есть еще одно важное различие. В отличие от основанных на архитектуре BIOS виртуальных машин первого поколения, виртуальные машины второго поколения построены на архитектуре Unified Extensible Firmware Interface (UEFI) и позволяют задействовать такие механизмы, как Secure Boot. Однако это изменение также провоцирует проблемы, как минимум для тех, кто захочет обновить виртуальную машину первого поколения до формата второго поколения.

Развертывания на основе архитектуры BIOS имеют системный раздел в формате NTFS, в то время как развертывания на основе архитектуры UEFI используют системный раздел Extensible Firmware Interface в формате FAT32. Таким образом, вы не можете просто взять виртуальные жесткие диски формата Virtual Hard Disk (VHD) от виртуальной машины первого поколения и прикрепить их к виртуальной машине второго поколения, использующей формат VHDX. Единственный способ провести обновления – использовать подход с применением резервного копирования, сняв образ операционной системы с виртуальной машины первого поколения и восстановив его на новую виртуальную машину второго поколения. Сложности могут возникнуть и при таком подходе, из-за изменений в аппаратной части и из-за того, что загрузочным устройством теперь является не контроллер IDE, а контроллер SCSI.

При этом нет причин беспокоиться об обновлении формата виртуальной машины, и между двумя форматами нет различия в производительности. Виртуальная машина второго поколения устанавливает и загружает операционную систему быстрее, чем машина первого поколения. Однако в производительности виртуальных машин после загрузки разницы нет.

На момент написания статьи виртуальные машины второго поколения поддерживают использование только 64-разрядных операционных систем версии Windows 8 и новее или Windows Server 2012 и новее. У виртуальных машин второго поколения нет модуля Compatibility Support Module (CSM), который в физической системе разрешает использование эмуляции BIOS, чтобы могли работать операционные системы, не основанные на интерфейсе UEFI OS. Следовательно, такие операционные системы не могут работать на виртуальных машинах второго поколения.

Выбрать, какое поколение использовать, достаточно просто. Если вам требуется обратная совместимость с предыдущими версиями гипервизора Hyper-V или работа с Windows Azure, задействуйте виртуальные машины первого поколения. Если обратная совместимость не нужна и вы используете поддерживаемые операционные системы, тогда смело выбирайте виртуальные машины второго поколения. Только имейте в виду, что вам понадобятся различные шаблоны для виртуальных машин первого и второго поколения, из-за несовместимости архитектур BIOS и UEFI.

Динамическое клонирование виртуальных машин

Версия Windows Server 2012 R2 вносит изменения в номенклатуру. То, что раньше называлось снимками – сохраненные состояния виртуальных машин на определенный момент времени – теперь называется контрольными точками. Это изменение унифицирует (приводит к единой номенклатуре) гипервизор Hyper-V и систему System Center Virtual Machine Manager (VMM).

Раньше у нас не было возможности экспортировать запущенную виртуальную машину или даже контрольную точку (снимок) виртуальной машины. Ситуация изменилась в версии 2012 R2 Hyper-V, которая позволяет экспортировать запущенные машины и контрольные точки запущенных машин. Данное изменение очень удобно для определенных сценариев. Например, предположим, что вы столкнулись с проблемой на виртуальной машине и хотите сохранить проблемное окружение прямо перед перезагрузкой и настройкой данной машины, чтобы иметь возможность в дальнейшем изучить проблему. Или представьте, что вы собираетесь создать тестовое окружение, основанное на производственных системах, но не хотите останавливать работу сервера. Процесс не изменился: у вас просто есть возможность экспортировать запущенную виртуальную машину или ее контрольные точки. Кроме того, экспорт можно выполнять с помощью команд Windows PowerShell с именами Export-VM и Export-VMSnapshot.

Режим расширенного сеанса

Для взаимодействия с виртуальной машиной вы обычно подключаетесь к операционной системе по протоколу RDP. Такой подход позволяет задействовать все возможности, доступные через протокол RDP, такие как буфер обмена, перенаправление принтеров и аудиоустройств, настройки экрана и т.д. Однако не всегда есть возможность подключиться к виртуальной машине по протоколу RDP. В качестве альтернативы приходится использовать функцию VMConnect, доступную при выборе действия Connect для виртуальной машины в диспетчере Hyper-V Manager. Возможности данного типа подключения исторически были сильно ограничены, он имеет жестко заданное разрешение и не обеспечивает перенаправление устройств или доступ к буферу обмена.

В версии Windows Server 2012 R2 Hyper-V впервые появился режим расширенного сеанса (Enhance Session Mode) для виртуальных машин с операционными системами Windows 8.1 и Windows Server 2012 R2. Создание данного режима стало возможным благодаря тому, что при перепроектировании операционных систем элементы протокола RDP были перенесены в архитектуру шины VMBus. При включенном режиме Enhanced Session Mode многие возможности протокола RDP теперь доступны при использовании функции VMConnect для подключения к виртуальной машине:

• настраиваемое разрешение;
• доступ к буферу обмена;
• перенаправления принтеров, аудиоустройств и дисков;
• доступ к смарт-картам и устройствам USB.

Данный режим значительно обогащает функциональность механизма VMConnect. Возможность вставлять данные из общего буфера обмена я считаю бесценной.

На экране 2 показано новое окно подключения для функции VMConnect. Вы можете задать разрешение экрана и перечень локальных ресурсов, которые необходимо сделать доступными. Обратите внимание на параметр Save my settings for future connections to this virtual machine. Если вы установите данный флаг, то все сохраненные настройки прописываются в папку %APPDATA%RoamingMicrosoftWindowsHyper-VClient1.0 с именем файла в формате vmconnect.rdp..config.

Экран 2. Новое окно подключения VMConnect

Несмотря на то, что стали доступны многие возможности RDP, подключение все равно рассматривается как административное, поэтому лицензия клиентского доступа Remote Data Services (RDS) не требуется. Вдобавок к обязательной установке на виртуальных машинах систем Windows 8.1 или Windows Server 2012 R2 для использования режима Enhanced Session Mode актуальны следующие требования:

• Серверная политика Enhanced Session Mode Policy в настройках сервера диспетчера Hyper-V Manager должна быть включена и установлена в значение Allow enhanced session mode. Эта политика по умолчанию отключена.
• В гостевой операционной системе должна быть запущена служба Remote Desktop Services, при этом активировать параметр Allow remote connections to this computer в настройках системы не обязательно.
• Авторизующийся пользователь должен быть членом группы локальных администраторов или группы пользователей удаленного рабочего стола в гостевой операционной системе.
• В гостевой системе должна быть завершена настройка при первом включении компьютера (этап OOBE).

Технически не являясь функцией режима Enhanced Session Mode, новая служба интеграции Guest, отключенная по умолчанию, представляет собой часть процесса расширенного взаимодействия и заслуживает упоминания. Когда эта новая служба интеграции включена, вы можете использовать команду Copy-VMFile оболочки PowerShell для копирования файлов на виртуальную машину, не устанавливая сетевое соединение. Такая возможность доступна только администраторам системы Hyper-V.

Автоматическая активация виртуальных машин

Активация виртуальных машин проблематична для многих организаций. Могут возникнуть комплексные трудности при перемещении виртуальных машин из вашего окружения в другие. Лицензия Windows Server Datacenter позволяет задействовать неограниченное количество виртуальных машин c операционной системой Windows Server, но при этом все равно должен быть предусмотрен способ активировать их:

• использовать ключ Multiple Activation Key (MAK);
• использовать ключ Key Management Service (KMS);
• использовать активацию на основе каталога Active Directory для систем Windows Server 2012 и более новых версий на машинах, присоединенных к домену.

В системе Windows Server 2012 R2 появился механизм автоматической активации виртуальных машин Automatic Virtual Machine Activation (AVMA). Как следует из названия, механизм AVMA, запущенный на активированном сервере Windows Server 2012 R2 Datacenter Hyper-V, автоматически активирует любую версию системы Windows Server 2012 R2. Единственный необходимый шаг – задействовать ключ AVMA в гостевой операционной системе, чтобы дать системе команду использовать механизм AVMA. Эти ключи перечислены в статье Automatic Virtual Machine Activation (technet.microsoft.com/en-us/library/dn303421.aspx):

• Windows Server 2012 R2 Datacenter—Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW;
• Windows Server 2012 R2 Standard—DBGBW-NPF86-BJVTX-K3WKJ-MTB6V;
• Windows Server 2012 R2 Essentials—K2XGM-NMBT3-2R6Q8-WF2FK-P36R2.

Если вы посмотрите на виртуальную машину с системой Windows Server 2012 R2 через диспетчер Device Manager, то увидите компонент Microsoft Hyper-V Activation среди устройств System. Используйте его для активации обмена информацией, связанной с активацией.

Улучшения в механизме динамической миграции

В системе Windows Server 2012 впервые реализована возможность динамической миграции между парой узлов. Процессы миграции динамически настраивают сами себя, основываясь на доступной полосе пропускания. Весь трафик динамической миграции отправлялся по сети в несжатом состоянии, поэтому, в зависимости от размера виртуальной машины, динамическая миграция могла занимать значительное время. Однако виртуальная машина была доступна во время динамической миграции, поэтому время выполнения не имело большого значения, если только вы не ждали, пока завершится миграция виртуальной машины с определенного узла, чтобы выключить этот узел для проведения обслуживания или с другой целью.

В системе Windows Server 2012 R2 появилось два новых параметра настройки динамической миграции.

• Compression. Этот параметр является новой настройкой по умолчанию и отвечает за сжатие данных при динамической миграции. Хотя сжатие потребляет дополнительные циклы процессора на обоих узлах Hyper-V (на исходном и целевом), оно кардинально сокращает время выполнения динамических миграций.
• SMB. Этот параметр отвечает за службу SMB Direct, механизм, использующий преимущества сетевых адаптеров, поддерживающих технологию Remote Direct Memory Access (RDMA). Технология RDMA позволяет передавать по сети огромные объемы данных, используя минимальный объем ресурсов хост-сервера. По сути, сетевой адаптер выделяет блок памяти и принимает меры для пересылки этого блока по сети. Операционная система хост-сервера даже не учитывает сетевые пакеты. Эта возможность обеспечивает наиболее быстрый процесс динамической миграции и использует меньшее количество ресурсов хост-сервера, но требует наличия сетевых адаптеров с поддержкой технологии RDMA.

Если у вас есть сетевые адаптеры с поддержкой RDMA, обязательно выбирайте режим SMB при настройке динамической миграции. В противном случае используйте режим Compression, предлагаемый по умолчанию.

В системе Windows Server 2012 R2 появилась еще одна важная, с учетом высокой частоты выхода новых версий системы Windows Server, функция динамической миграции: динамическая миграция между версиями. Динамическая миграция между версиями позволяет выполнять динамическую миграцию с хост-сервера версии Windows Serve 2012 Hyper-V на хост-сервер версии Windows Server 2012 R2 Hyper-V. Эта возможность означает, что в процессе миграции в работе виртуальной машины не будет простоев. Такой функции очень не хватало пользователям Hyper-V, не желавшим допускать простоев в работе даже при обновлении гипервизора Hyper-V.

Изменения в механизме реплики Hyper-V

Механизм Hyper-V Replica позволяет выполнять асинхронную репликацию виртуальных машин с одного отдельного или входящего в состав кластера хост-сервера Hyper-V на другой. Такая возможность полезна для аварийного восстановления. Информацию еще об одном механизме обеспечения отказоустойчивости Hyper-V, который не является нововведением в системе Windows Server 2012 R2, можно найти во врезке «Hyper-V Recovery Manager».

Благодаря асинхронному характеру репликации виртуальная машина может быть реплицирована между центрами обработки данных, что не окажет влияния на производительность исходной виртуальной машины. Механизм Hyper-V Replica реплицирует диски VHD виртуальных машин и позволяет выполнять различные типы аварийного восстановления, в том числе запланированное, незапланированное и тестовое. Кроме того, есть возможность во время аварийного восстановления присвоить виртуальной машине альтернативный IP-адрес. Площадки, на которые выполняется аварийное восстановление, обычно имеют схему IP-адресации, отличную от основного центра обработки данных. В системе Windows Server 2012 частота выполнения репликации зафиксирована в значении 5 минут.

Изначально задачей механизма Hyper-V Replica была репликация между центрами обработки данных. Но некоторые организации использовали функции Hyper-V Replica внутри одного центра обработки данных. Например, для репликации виртуальных машин между кластерами Hyper-V или между одиночными хост-серверами Hyper-V, на которых не могла использоваться кластеризация. Таким клиентам требовалась возможность выполнять репликацию чаще чем раз в 5 минут и отсылать дополнительную реплику виртуальной машины в центр обработки данных. Последнее требование было невыполнимо, так как виртуальная машина может иметь только одну реплику.

Механизм Hyper-V Replica в системе Windows Server 2012 R2 приобрел две новые функции, которые помогут закрыть описанные выше потребности. Во-первых, настройки частоты репликации стали более гибкими: есть возможность установить значения в 30 секунд, 5 минут или 15 минут. Во-вторых, можно расширить репликацию.

Расширенный механизм Hyper-V Extended Replica позволяет создавать реплики реплик, как показано на рисунке. Имейте в виду, что у дополнительной реплики есть собственная частота создания. Вы по-прежнему не можете иметь более одной реплики отдельной виртуальной машины: например, виртуальная машина на сервере А не в состоянии напрямую посылать реплику на серверы В и С. Но, как мы видим на рисунке, реплику можно отправить с одного сервера на другой, после чего эта реплика виртуальной машины сможет послать свою реплику на третий узел.

Рисунок. Расширенный механизм Hyper-V Extended Replica

Новый расширенный набор функций позволяет реализовать множество дополнительных сценариев. Например, можно выполнять репликацию внутри центра обработки данных с частотой в 30 секунд, после чего отправлять дополнительную реплику в другой центр обработки данных с частотой в 30 секунд, 5 минут или 15 минут. Один важный момент: дополнительная реплика не может создаваться с большей частотой, чем основная реплика. Например, если основная реплика создается каждые 5 минут, то дополнительная реплика может создаваться с частотой в 5 или 15 минут, но не каждые 30 секунд.

В этой статье я уделил внимание основным изменениям в гипервизоре Hyper-V, но они составляют только половину всех новых возможностей. В следующей статье мы продолжим погружение в Windows Server 2012 R2 Hyper-V. Многие улучшения, касающиеся других областей систем Windows Server и System Center будут полезны в виртуальных окружениях, так что выделите время на изучение всех аспектов систем Windows Server, System Center и Windows Azure.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Прежде всего внесем ясность в термины. Hyper-V — это бесплатный гипервизор от компании Microsoft, работающий на платформе Windows. Первоначально поддерживались только серверные версии, но начиная с Windows 8 (редакции не ниже Pro) его можно использовать и в настольных ОС. Несмотря на то, что Microsoft явно не обозначает редакции гипервизора, новые поколения ОС содержат в себе новые версии Hyper-V. Так как степень интеграции Hyper-V в ОС достаточно велика, то вы не можете обновить версию гипервизора отдельно от версии ОС.

Если ориентироваться по версии конфигурации виртуальных машин, то можно говорить о восьми поколениях Hyper-V, версию 8.0 содержат Server 2016 и Windows 10 (1607). Наиболее распространенные Windows Server 2012 R2 (и Windows 8.1) имеют пятое поколение гипервизора.

Таким образом, если мы хотим использовать последнюю версию гипервизора, то нам нужна последняя версия ОС. А так как лицензии на Windows не допускают использования более поздних выпусков ОС, то бесплатный Hyper-V может оказаться не таким уж бесплатным. Аналогичные затруднения возникают при виртуализации уже существующих сред, покрытых лицензиями на более ранние версии Windows или виртуализации UNIX-систем. Специально для таких случаев Microsoft выпустила специальный продукт — Hyper-V Server.

Hyper-V Server — специальный выпуск на основе Windows Server Core с сильно урезанными функциями, обеспечивающими только работу гипервизора и его обслуживание. При этом, вопреки распространенному мнению, никакой разницы между Hyper-V Server и Hyper-V в качестве роли Windows Server нет. Это один и тот-же продукт.

Когда говорят о Hyper-V Server и Windows Server Core, то в первую очередь пытаются сделать упор на экономию ресурсов за счет отсутствия GUI, однако это мнение ошибочно. При создании данных продуктов вопрос экономии ресурсов стоял в последнюю очередь, да и глупо говорить о каком-либо «недостатке ресурсов» на гипервизоре.

Основная цель создания Windows Server Core и Hyper-V Server — это сокращение количества работающих служб и компонентов системы, что позволяет уменьшить площадь атаки (меньше служб — меньше уязвимостей) и существенно сократить затраты на сопровождение системы, например, меньшее количество перезагрузок при обновлении системы и меньшее время установки обновлений. Поэтому о внедрении именно Hyper-V Server стоит подумать даже если вы не испытываете затруднений с лицензированием.

Установка и первоначальная настройка Hyper-V Server

Образ для установки можно получить на официальном сайте, после регистрации, если у вас до сих пор не было учетной записи Microsoft. Процесс установки ничем не отличается от установки иных версий Windows и не должен вызвать затруднений.

По ее завершению нас встречает предельно лаконичный интерфейс с двумя открытыми окнами: командной строки и текстовой утилиты конфигурирования.

Если вы закрыли последнее, то чтобы снова вызвать данную утилиту просто выполните команду:

sconfig

А вот если вы закрыли все окна, включая окно командной строки, то можете внезапно оказаться перед черным экраном без средств управления системой вообще. В этом случае нажмите Ctrl+Shift+Esc (данная комбинация работает также через RDP) и при помощи вызванного диспетчера задач запустите нужный вам процесс, например, командную строку.

Перейдем к настройке. В первую очередь следует настроить сеть, указать имя сервера, его членство в нужной рабочей группе или домене и разрешить удаленный рабочий стол. Также, если вы хотите, чтобы ваш сервер отвечал на команду ping, то следует перейти в пункт 4) Настройка удаленного управления и выбрав опцию 3) Настройка отклика сервера на сообщение проверки связи явно разрешить это действие.

Затем укажите параметры обновления сервера и установите все имеющиеся на данный момент обновления. С ручной установкой связан один «сюрприз»: указанные в утилите символы не действуют, и чтобы скачать и установить все доступные обновления нужно при запросах вводить маленькую русскую букву т.

После завершения настройки и установки обновлений сервер следует перезагрузить. Здесь может возникнуть вполне закономерный вопрос: а что делать дальше? Как им управлять? Для управления Hyper-V Server понадобится еще один компьютер с установленными средствами управления Hyper-V, а настройки самого сервера можно производить из консоли MMC. Для этого создадим нужные разрешающие правила в брандмауэре. Для этого запустим PowerShell и последовательно выполним следующие команды:

powershell
Enable-NetFirewallRule -DisplayGroup "Удаленное управление Windows"
Enable-NetFirewallRule -DisplayGroup "Удаленное управление журналом событий"
Enable-NetFirewallRule -DisplayGroup "Удаленное управление томами"
Enable-NetFirewallRule -DisplayGroup "Дистанционное управление рабочим столом"

На этом настройку сервера следует считать законченной, можно проверить подключение к нему средствами RDP и, если все прошло нормально, переходить к настройке клиентской станции.

Настройка клиента для работы с Hyper-V Server

Для управления Hyper-V Server вам понадобится ПК с ОС не ниже Windows Server 2012R2 или Windows 8.1 редакции Pro или Enterprise, мы будем рассматривать дальнейшую настройку на примере клиентских ОС. Домашние и 32-разрядные версии ОС не подойдут, так как в них нет возможности установить диспетчер Hyper-V.

Так как сетевое обнаружение и общий доступ к файлам и принтерам на сервере выключен, то нужно добавить для него на DNS-сервера запись типа А, связывающую имя сервера и его IP-адрес или внести соответствующую строку в файл hosts, в нашем случае она выглядит так:

192.168.18.145 HV-CORE-2012R2

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

cmdkey /add:ServerName /user:UserName /pass:password

где ServerName — имя сервера Hyper-V, UserName — имя администратора сервера Hyper-V и password — его пароль.

Если вы используете Windows 10, то дополнительно запустите командную строку (или консоль PowerShell) от имени администратора и выполните там команды:

winrm quickconfig
winrm set winrm/config/client '@{TrustedHosts="ServerName"}'

где ServerName — имя сервера Hyper-V.

Затем запустите оснастку dcomcnfg, через Win+R или из командной строки, и разверните дерево Службы компонентов — Компьютеры — Мой компьютер. После чего в по щелчку правой кнопки мыши выберите Свойства и перейдите на закладку Безопасность COM — Права доступа — Изменить ограничения и в открывшемся окне установите для пользователя АНОНИМНЫЙ ВХОД права Удаленный доступ.

Выполнив данные настройки можно запустить консоль MMC Управление компьютером и щелкнув правой кнопкой на одноименном корневом пункте выберите Подключение к другому компьютеру и укажите имя сервера Hyper-V.

После чего вы можете управлять удаленным сервером используя привычный набор инструментов. Для решения большинства повседневных задач оснастки Управление компьютером вполне достаточно, особенно если учесть, что большинство настроек делаются всего один раз.

Для того, чтобы использовать оснастку Управление дисками предварительно потребуется запустить службу Виртуальный диск, это можно сделать прямо здесь, через оснастку Службы.

Единственной недоступной оснасткой будет Диспетчер устройств, настроить его работу можно, но практического смысла в этом нет, так как работать он все равно будет в режиме «только чтение». К тому же по факту это не представляет проблемы: база драйверов Windows Server достаточно обширна и если вы проявили разумную предусмотрительность при выборе оборудования, то к вопросу драйверов вам вообще обращаться не придется.

В противном случае вам следует обратиться к инструментам командной строки для работы с драйверами: 1.6. Установка оборудования и управление драйверами (локально)

Наконец мы подошли к самому главному. Перейдем в классическую Панель управления — Программы и компоненты — Включение и отключение компонентов Windows и установим Средства управления Hyper-V.

После чего вы получите в свое распоряжение привычный инструмент управления Hyper-V который позволяет полноценно управлять гипервизором. Никаких особенностей в работе с Hyper-V сервер нет, поэтому мы не будем останавливаться на этом вопросе более подробно.

Для того, чтобы передавать на гипервизор файлы, например, образа для установки, можно воспользоваться стандартными общими ресурсами, скажем, набрав в адресной строке проводника:

\ServerNameC$

вы попадете на диск С: сервера.

Для примера мы создали новую виртуалку и установили туда свежую версию Debian, не испытав каких-либо затруднений ни при работе с гипервизором, ни с самой виртуальной машиной.

Как видим, несмотря на несколько более сложный процесс установки и настройки Hyper-V Server представляет собой удобный и надежный инструмент, который к тому же можно использовать полностью бесплатно.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Обновлено 05.03.2015

Добрый день уважаемые читатели блога pyatilistnik.org, сегодня хочу рассказать как установить Hyper-V в Windows Server 2012R2, ранее я уже рассказывал Как установить Hyper-V роль в Windows server 2008R2, время не стоит на месте и вышел уже гипервизор 3 поколения. Для установки вам потребуется Windows Server 2012R в редакции либо Hyper-V 2012R2 либо standart, датацентр ставить смысла нету так как по функционалу он ничем не отличается от Windows server 2012 standart. Если вдруг не знаете как поставить виндоус, то советую прочитать статью Как установить windows server 2012R2.

Установка Hyper-v 3.0 как и любая установка у Microsoft процесс очень простой, приступим. Запускаем Диспетчер сервера и нажимаем добавить новую роль

Первое окно мастера сразу пропускаем и жмем далее.

оставляем выбранным пункт Установка ролей или компонентов, жмем далее

Выбираем сервер из пула серверов и жмем далее

На данном этапе мастера установки, отметьте галку Hyper-V и нажмите далее

Жмем далее

Читаем вводную информацию установки и жмем далее

На данном этапе нам предлагают настроить сеть и выбрать сетевые адаптеры, ничего не выбирайте мы это настроим в следующей части.

Настройкой миграции мы займемся тоже позже, так что галку не ставим и жмем далее

Теперь нужно задать где будет располагаться хранилище наших настроек и виртуальных машин, советую выделить отдельный диск под это дело.

Жмем Установить

после установки Hyper-v вас попросят перезагрузиться

После перезагрузки, открываем пуск и видим что у нас добавилась оснастка Диспетчер Hyper-v

Открываем ее и видим, привычную оснастку Hyper-V

Вот так вот просто установить Hyper-V в Windows Server 2012R2, в следующей статье мы его до настроим и создадим виртуальные машины. Так же советую почитать Как настроить виртуальный коммутатор в Hyper-v 3.0 в Windows Server 2012R2.

В статье подробно описан процесс установки и настройки роли Hyper-V, создание виртуальной машины, а также настройка сетевого взаимодействия и запуск виртуальной машины на Windows Server 2012 R2.

Для установки роли Hyper-V на Windows Server 2012 R2 потребуется компьютер, под управлением Windows Server 2012 R2 (О том как установить Windows Server 2012 R2 можно прочитать в данной статье: «Установка и активация Windows Server 2012 R2 c USB флешки» ).

I. Установка роли Hyper-V на Windows Server 2012 R2

1. Откройте окно диспетчера сервера и выберите пункт Добавить роли и компоненты (Рис.1).

Рис.1

.

2. В появившемся окне нажмите Далее (Рис.2).

Рис.2

.

3. Выберите пункт Установка ролей и компонентов, затем нажмите Далее (Рис.3).

Рис.3

.

4. Выберите сервер на который будет производиться установка роли, затем нажмите Далее (Рис.4).

Рис.4

.

5. Поставьте галочку напротив Hyper-V (Рис.5).

Рис.5

.

6. Мастер установки ролей предупредит, что для установки роли Hyper-V нужно установить несколько компонентов. Нажмите Добавить компоненты (Рис.6).

Рис.6

.

7. Убедитесь, что после установки необходимых компонентов напротив Hyper-V стоит галочка, затем нажмите Далее (Рис.7).

Рис.7

.

8. На этапе добавления компонентов оставьте все значения по умолчанию и нажмите Далее (Рис.8).

Рис.8

.

9. Ознакомьтесь с дополнительной информацией касательно Hyper-V, затем нажмите Далее (Рис.9).

Рис.9

.

10. Мастер добавления ролей и компонентов предложит настроить сеть и выбрать сетевые адаптеры, ничего не выбирайте (настройку можно будет произвести позднее) и нажмите Далее (Рис.10).

Рис.10

.

11. Настройку миграции тоже можно произвести позднее, нажмите Далее (Рис.11).

Рис.11

.

12. Оставьте настройки по умолчанию и нажмите Далее (Рис.12).

Рис.12

.

13. Нажмите Установить (Рис.13).

Рис.13

.

14. Начнётся процесс установки (Рис.14).

Рис.14

.

15. После окончания установки нажмите Закрыть, затем перезагрузите сервер (Рис.15).

Рис.15

.

16. После перезагрузки откройте Диспетчер серверов, в левой колонке Вы увидите пункт Hyper-V (Рис.16). На этом установка роли Hyper-V в Windows Server 2012 R2 закончена.

Рис.16

.

II. Создание виртуальной машины в Hyper-V

1. Откройте Диспетчер серверов, затем Средства и выберите Диспетчер Hyper-V (Рис.17).

Рис.17

.

2. В открывшемся окне нажмите Создать (Рис.18).

Рис.18

.

3. В открывшемся меню выберите Виртуальная машина… (Рис.19).

Рис.19

.

4. В открывшемся окне Мастера создания виртуальной машины нажмите Далее (Рис.20).

Рис.20

.

5. В поле Имя введите имя для новой виртуальной машины (прим. в данном руководстве это DemoVM), затем нажмите Далее (Рис.21).

Рис.21

.

6. Выберите поколение виртуальной машины, затем нажмите Далее (Рис.22).

Рис.22

.

7. Поставьте галочку напротив Использовать для этой виртуальной машины динамическую память, затем нажмите Далее (Рис.23).

Рис.23

.

8. В окне настроек сети — нажмите Далее (Рис.24).

Рис.24

.

9. Выберите пункт Создать виртуальный жесткий диск, затем установите размер диска, после чего нажмите Далее (Рис.25).

Рис.25

.

10. Выберите пункт Установить операционную систему позднее, затем нажмите Далее (Рис.26).

Рис.26

.

11. Для создания виртуальной машины и закрытия мастера нажмите Готово (Рис.27). На этом создание виртуальной машины завершено.

Рис.27

.

III. Настройка сетевого взаимодействия

1. Откройте Диспетчер Hyper-V и выберите Диспетчер виртуальных коммутаторов (Рис.28).

Рис.28

.

2. Выберите необходимый тип виртуального коммутатора (прим. описание для каждого типа указаны в диспетчере виртуальных коммутаторов ниже. В данном руководстве будет использоваться Внешний тип виртуального коммутатора), затем нажмите ОК (Рис.29).

Рис.29

.

3. В поле Имя введите имя для виртуального коммутатора (прим. в данном руководстве это Demo Virtual switch). Выберите пункт Внешняя сеть и укажите Сетевое подключение, затем поставьте галочку напротив Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру, нажмите Применить и ОК (Рис.30).

Рис.30

.

4. В появившемся окне предупреждения нажмите Да (Рис.31).

Рис.31

.

5. Откройте Диспетчер Hyper-V, выберите виртуальную машину (прим. в данном руководстве это DemoVM), откройте меню (пр. кнопкой мыши) и выберите Параметры… (Рис.32).

Рис.32

.

6. В окне Параметров выберите Сетевой адаптер, затем укажите виртуальный коммутатор (прим. в данном руководстве это Demo Virtual switch) (Рис.33).

Рис.33

.

7. После того как Вы выбрали виртуальный коммутатор, нажмите Применить, затем ОК (Рис.34). На этом настройка сети завершена.

Рис.34

.

IV. Запуск виртуальной машины в Hyper-V

1. Откройте Диспетчер Hyper-V и выберите Параметры… (Рис.35).

Рис.35

.

2. Выберите DVD-дисковод, затем пункт Файл образа и нажмите Обзор… (Рис.36).

Рис.36

.

3. Выберите ISO-образ операционной системы (прим. в данном руководстве, в качестве примера, используется Windows Server 2012 R2) и нажмите Открыть (Рис.37).

Рис.37

.

4. Нажмите Применить, затем ОК (Рис.38).

Рис.38

.

5. В Диспетчере Hyper-V выберите виртуальную машину, вызовите меню (пр. кнопкой мыши) и нажмите Пуск (Рис.39).

Рис.39

.

6. Сделайте двойной клик на названии виртуальной машины, после чего откроется окно запущенной виртуальной машины (Рис.40).

Рис.40

.

Установка и настройки роли Hyper-V, создание виртуальной машины, а также настройка сетевого взаимодействия и запуск виртуальной машины на Windows Server 2012 R2 произведены! Надеемся, что данное руководство было для Вас полезно!

.