Приложение A. Архитектура и компоненты Hyper-V

VMM (Virtual Machine Manager, Диспетчер виртуальных машин), также известный как Hypervisor (Гипервизор), является тем программным обеспечением, которое отвечает за исполнение множества ВМ в одной системе. Он также отвечает за создание, сохранность, деление, доступ к системе и управление ВМ на уровне Гипервизора.

Имеются следующие типы Гипервизоров:

Данный тип Гипервизора исполняется поверх имеющейся ОС. В основании у нас имеется оборудование, сама ОС и затем Гипервизор, работающий поверх них, как это отображается на следующей схеме:

Microsoft Virtual PC и VMware Workstation являются примерами программного обеспечения, которое применяет VMM 2 типа.

ВМ передают аппаратные запросы в Гипервизор, оттуда в ОС хоста и затем они наконец достигают самой аппаратуры. Это влечёт за собой ограничения на производительность и управление, вызываемые ОС хоста.

Тип 2 обычен для сред тестирования - ВМ с ограничениями оборудования - для исполнения прикладных программных средств, устанавливаемых в ОС самого хоста.

Когда мы применяем Гибридный тип VMM, Гипервизор работает на том же самом уровне, что и ОС, как это отображено на схеме внизу. Поскольку и Гипервизор, и ОС имеют один и тот же доступ к общим аппаратным средствам, причём с одним и тем же приоритетом, это не так быстро и безопасно, как могло бы быть. Этот тип применялся в предшественнике Hyper-V с названием Microsoft Virtual Server 2005:

VMM 1 типа является той разновидностью, которая имеет Гипервизор исполняющимся в тонком программном уровне между оборудованием и имеющимися разделами (partitions), а также управляет и координирует (orchestrating) доступ к аппаратным средствам. ОС самого хоста, называемая Родительским разделом (Parent Partition), работает на том же самом уровне, что и Дочерний раздел (Child Partition), называемый ВМ, что отображено на схеме внизу. Благодаря привилегированному доступу к аппаратным средствам, который имеется у Гипервизора, ему предоставляется большие безопасность, производительность и управление, нежели имеется у всех разделов. Данный тип применяется Hyper-V начиная с его первого выпуска:

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

Прежде чем мы погрузимся в подробности архитектуры Hyper-V, будет проще понять что произойдёт после установки Hyper-V, взглянув на Windows без Hyper-V, что отображено на схеме внизу:

В установленном обычным образом Windows доступ инструкция подразделяется на четыре уровня привилегий в процессоре, называемых Кольцами (Ring). Наиболее привилегированным является Ring 0, имеющий прямой доступ к оборудованию и именно в нём располагается Ядро (Kernel) Windows. Ring 3 отвечает за размещение пользовательского уровня и именно в нём исполняется большая часть приложений с наинизшим уровнем привилегий доступа.

После установки Hyper-V ему необходимы более высокие привилегии, чем имеются у Ring 0. Помимо этого он должен иметь выделенный доступ ко всему оборудованию. Это возможно благодаря новым возможностям самых последних создаваемых Intel и Amd процессоров, называемых Intel-VT и AMD-V, соответственно, которые позволяют создание пятого кольца с названием Ring -1. Hyper-V применяет это кольцо для добавления своего Гипервизора, имеющего более высокие привилегии и выполняющегося под Ring 0, управляющим всем доступом к физическим компонентам, как это отображает следующая схема:

Сама архитектура ОС претерпевает некоторые изменения после установки Hyper-V. Сразу после первой загрузки, файл Начальной загрузки операционной системы (Operating System Boot Loader, winload.exe) проверяет используемый процессор и загружает образ Гипервизора в -1 Кольцо (применяя соответствующие файлы Hvix64.exe для процессоров Intel и Hvax64.exe для процессоров AMD. Затем Windows Server устанавливается для работы поверх Гипервизора и все ВМ работают в нём.

После установки Hyper-V Windows Server имеет тот же самый уровень привилегий, что и ВМ и отвечает за управление ВМ с использованием различных компонентов.

Hyper-V имеет множество компонентов, которые отвечают за предоставление решения повсеместного управления ВМ и свою ОС управления (Management OS). Приводимая ниже схема показывает наиболее важные компоненты Hyper-V, которые будут объясняться в последующих разделах:

Небольшой Гипервизор Hyper-V (почти 20 МБ) отвечает за управление, отделение и контроль доступа к разделам (Partitions). Кроме того он отвечает за изоляцию всех разделов друг от друга в высокой безопасностью и надёжностью.

При наличии Hyper-V сама ОС хоста и все ВМ исполняются и разделяют одни и те же доступ и привилегии в Гипервизоре и все они носят название Разделов (Partitions). Однако ОС хоста исполняет последовательности компонентов для управления своими ВМ и по этой причине имеет название Родительского раздела (Parent partition) или ОС управления, а ВМ называются Дочерними разделами (Child partitions) или Гостевыми ОС.

Создание и исполнение ВМ осуществляется последовательностью виртуальных устройств и программных компонентов, имеющих название Стека виртуализации, который исполняется в Родительском разделе. Эти последовательности компонент работают совместно со своим Гипервизором.

VSP (Virtualization Service Provider Поставщик службы виртуализации) является компонентом, который управляет запросами ввода/ вывода в основании данной ВМ в её Родительском разделе. VMBus (Virtual Machine Bus, Шина виртуальной машины) отвечает за обмен данными, обслуживание и доставку устройств между разделами Родителя и Дочерними через выделенные каналы, доступные между VSP и VSCs (Virtualization Service Clients, Виртуальными службами клиентов). VSP применяет VMBus для взаимодействия с Дочерними разделами используя VSCs для предоставления синтетических (искусственных) драйверов, исполняющихся в Дочерних разделах.

Для каждой запущенной ВМ в её Родительском разделе создаётся рабочий процесс (Worker process). Рабочий процесс и VMMS (Virtual Machine Management Service, Служба управления Виртуальными машинами) являются компонентами режима пользователя, которые предоставляют Родительскому разделу ту самую возможность создания, запуска, останова, сохранения и удаления ВМ. Все эти задачи координируются VID (Virtual Infrastructure Driver, Драйвером виртуальной инфраструктуры), который управляет взаимодействием между Родительским и Дочерними разделами.

Доступ между разделами и Гипервизором осуществляется специальным интерфейсом, имеющим название Гипервызовов (Hypercall). Это обеспечивает то, что все ВМ могут осуществлять доступ к оборудованию с использованием таких компонентов как VID, VMBus, VSCs и VSPs. Эти механизмы предоставляются в процессе установки ICs (Integration Components, Компонентов интеграции). Некоторые операционные системы Windows и Linux имеют уже установленные в их Ядрах (Kernel) пакеты компонентов интеграции. Имеющие эти компоенеты ВМ имеют название Информированных ВМ (Enlightened VM). Для старых ОС или ОС не имеющих такой поддержки, сам Родительский раздел перехватывает взаимодействие ВМ, эмулируя все Гипервызовы. Результатом является более низкая производительность, поскольку ОС управления требуется работать в качестве моста чтобы сделать возможным доступ всем ВМ к имеющемуся оборудованию. Именно поэтому очень важно чтобы все имеющиеся ВМ работали с самой последней версией IC.

В Windows Server 2016 Hyper-V, Microsoft сделал достаточно значительные изменения в имеющуюся архитектуру резервного копирования. Они дают Hyper-V такую поддержку, что любой, включая партнёров резервного копирования, может осуществлять запросы к WMI Hyper-V и запрашивать моментальные снимки VSS (Volume Shadow Copy Service, Службы теневой копии тома) для любой ВМ, а затем двигаться далее и сделать независимым весь процесс резервного копирования.

В Hyper-V Windows Server 2016 вся архитектура резервного копирования выглядит аналогично приводимой ниже схеме:

Как вы видите на схеме, внизу у нас имеется наш хост Hyper-V; приложение резервного копирования вначале вызывает WMI Hyper-V для получения всех ВМ, для которых оно желает выполнить резервное копирование в любом Наборе бекапов и затем данное приложение резервного копирования вызовет VSS и VDS (Virtual Disk Service, Службу виртуального диска) для организации (orchestrate) отдельного моментального аппаратного снимка в сервере хранения. Основная цель здесь состоит в получении модели, при которой вне зависимости от того, сколько у вас имеется ВМ, а ткаже вне зависимости от имеющегося у вас масштаба она не должна оказывать воздействие на вашу систему.

Если мы сравним резервное копирование с предыдущим редакциями Hyper-V, имелось два возможных варианта осуществления моментальных снимков:

Для RCT и MRT имеются две цели. Первая состоит в улучшении резервного копирования всех предыдущих архитектур Hyper-V, что имело результатом полное резервное копирование всех виртуальных жёстких дисков данных ВМ, что означает, что всякий раз, когда вы выполняете резервное копирование (ежедневное, выполняемое каждый час или какое- либо другое), все данные отправляются через сетевую среду всякий раз и всегда, причём эта архитектура не может достаточно хорошо масштабироваться. Следовательно, чтобы избежать отправки всех необходимых даныых через имеющуюся сетевую среду, все производители резервного копирования, в настоящее время, реализуют фильтрацию файловой системы для отслеживания изменений блоков в данном хранилище, однако наличие сторонних фильтров файловой системы в ядре ОС хоста является потенциально приводящей к крушению системы ошибкой, а вторая проблема будет воздействовать на профилирвоание производительности хранилища. В Windows Server 2016 Microsoft построил некоторую систему, в которой у вовсе вас нет нужды помещать какой- либо фильтр файловой системы, имеется расширенный период времени, в течени и которого все ВМ будут исполняться с файлами .avhdx, или дисками приращений, причём Microsoft старается подавить воздействие этого на производительность.

В Windows Server 2016, Microsoft предоставляет естественное отслеживание изменение блока как некоторую часть всей платформы. При помощи RCT и MRT он может получать таблицу размещения блоков, которая имеется в каждом файле виртуального жёсткого диска (.VHDX), а также хранить отслеживание всех изменённых блоков; однако они не записывают эти данные, поскольку конкретное приложение резервного копирования имеет ещё где-то копию первоначальных данных, что тем самым предотвращает двойное копирование таких данных. Величайшее достижение RCT и MRT состоит в том, что они тесно вплетены в файл VHDX; таким образом, где бы не существовал этот файл, они остаются вместе с ним, что очень очень удобно когда дело доходит до сценариев мобильности ВМ и устойчивости к разрушению файла VHDX.

Файл MRT записывается в режиме сквозной записи и применяет крупную грануляцию отслеживания; в то время как файл RCT имеет более тонкую грануляцию и применяет обычную запись. Режим сквозной записи (write-through) обеспечивает даже в случае внезапной утраты электропитания сам файл MRT всё ещё будет иметь надлежащую запись того, что было изменено на данном диске. Файл RCT имеет более тонкую гранулированность (16k)для лучшего соответствия сценарию, необходимому на протяжении обычных действий. Эти файли были разделены для улучшения общей производительности хранения. Весь файл RCT не будет превышать 6 МБ, а файл MRT не будет расти выше 76 кБ.

Следующий снимок экрана отображает отслеживание изменения блока в Hyper-V Windows Server 2016 в процессе операции резервного копирования:

Имеются два важных момента применения VHDX, о которых следует знать, если вы планируете исполнять ВМ с VHD вместо VHDX в Windows Server 2016, поскольку если ваша ВМ имеет версию 5.0, тогда вы не получите каких- либо преимуществ от поддержки RCT. Применение ВМ с настройкой версии 5.0 может иметь место на хостах, работающих под управлением Windows Server 2012 R2 и 2012 R2, которые не поддерживают RCT; поэтому если вы находитесь в любой из этих ситуаций, вы получите воздействие на производительность в процессе резервного копирования, поскольку Microsoft в данном случае не будет применять RCT и вместо этого будет использовать диск приращений (аналогично Windows Server 2012 R2). Microsoft также поддерживает резервное копирование для гостевых кластеров в Windows Server 2016 с применением инфраструктуры RCT, причём гостевые кластеры являются группами ВМ, совместно использующими виртуальные жёсткие диски. Однако, для того чтобы осуществлять это, Microsoft ввёл новый формат файла с названием VHDX (VHD Set) VHDS является очень маленьким файлом, который имеет целую пачку файлов .avhdx, сопровождающих его.

С введенирем файла набора VHD (VHD Set), Microsoft может получать преимущество такого хранения моментального снимка и затем обновлять все настройки ВМ чтобы соответствовать правильной конфигурации. Сам файл VHDS является файлом относительных ссылок и содержит метаданные контрольных точек. Никакие данные пользователей не хранятся в самом файле VHDS. Вы можете представлять себе файл VHDS как внешний файл совместно используемых между ВМ (гостевыми кластерами) настроек, поскольку в Windows Server 2012 R2, если у вас есть две ВМ, использующих совместно файл VHDX, тогда каждая ВМ имеет свой собственный файл настроек, что создаёт существенные проблемы при обновлении метаданных и повторной синхронизации всех имеющихся изменений. Однако, в Windows Server 2016, если у вас имеются две ВМ гостевого кластера, причём каждая имеет свою собственную конфигурацию, зависящую от совместно используемого файла VHDS, который является на самом деле файлом настроек, это делает для нас возможным иметь одно место для обновлений в случае, когда присутствуют изменения в лежащем в основе всего хранилище. Файл Набора VHD (VHD Set) позволяет решать проблемы, связанные с координацией обновлений во всех конфигурациях ВМ путём централизации всех путей файлов VHD в едином файле Набора VHD. Файл Набора VHD также предоставляет использование в GUI или в PowerShell некоторого дружественного имени файла. Файл Набора VHD может применяться аналогично любому прочему файлу VHD; он может запрашиваться, мигрировать и монтироваться. Первичной причиной для файла Набора VHD (VHDS) является наличие поддержки для резервного копирования в гостевых кластерах.

Роль, которая устанавливается на Windows Server 2016 (Сервер ядра или Полный сервер), Роль, которую можно установить на Нано сервер, его свободно распространяемая версия с названием Сервер Hyper-V, а также Hyper-V, который поставляется с Windows 10 под названием Клиента Hyper-V, все они являются четырьмя различными версиями Hyper-V. Следующий раздел разъяснит различия между всеми этими версиями и сравнит Hyper-V с его конкурентом, VMwrae.

Начиная со своей первой версии, Hyper-V был сильно улучшен. Новые ограничения, в сравнении с предыдущей версией, повышены в 16 раз. Это достаточно выразительно для третьего выпуска.

Приводимая ниже таблица отображает улучшения на основе Hyper-V Windows Server 2008 R2:

Ресурс	Windows Server 2008 R2 Hyper-V	Windows Server 2012 R2 Hyper-V	Windows Server 2016 Hyper-V
Логические процессоры	64	320	512
Физическая память	1ТБ	4ТБ	24ТБ
Виртуальных ЦПУ на хост	512	2 048	2 048
Виртуальных ЦПУ на ВМ	4	64	240
Память ВМ	64ГБ	1ТБ	12ТБ
Активных ВМ на хост	384	1 024	1 024
Узлов на кластер	16	64	64
Максимальное число ВМ на кластер	1 000	8 000	8 000

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

Hyper-V может быть установлен в качестве роли и в Стандартной редакции Windows Server, и в редакции Центра данных.

Единственная разница между Windows Server 2012 и 2012 R2 в Стандартной редакции состоит в лицензировании двух свободных версий ОС Windows Server, в то время как в редакции Центра данных число лицензий не ограничено.

Однако, в Windows Server 2016 имеются существенные различия между данными двумя редакциями.

Приводимая далее таблица отображает разницу между Стандартной редакцией и редакцией Центра данных в Windows Server 2016:

Ресурс	Редакция Центра данных Windows Server 2016	Стандартная редакция Windows Server 2016
Основная функциональность Windows Server	Да	Да
Число ОС/ Контейнеров Hyper-V	Без ограничений	2
Число Контейнеров Windows Server	Без ограничений	Без ограничений
Нано сервер	Да	Да
Функции хранения для программно управляемого центра данных включая Непосредственно подключаемые Пространства хранения и Реплику хранения	Да	Не доступны
Ограждённые ВМ	Да	Не доступны
Сетевой стек для программно управляемого центра данных	Да	Не доступны
Модель лицензирования	Ядро + CAL	Ядро + CAL

Как вы можете отметить в предыдущей таблице, редакция Центра данных спроектирована для частных и гибридных окружений с высокой степенью виртуализации, а Стандартная редакция служит для (физических) сред с низкой степенью виртуализации либо без неё.

В Windows Server 2016, для редакций Стандартной и Центра данных, Microsoft также изменил модель лицензирования с по-процессорной на лицензирование по ядрам.

Следующие моменты послужат вам руководством для лицензирования Стандартной редакции и редакции Центра данных Windows Server 2016:

Следующая таблица иллюстрирует новую модель лицензирования на основе общего числа лицензий из пакетов по два ядра:

Общее число необходимых лицензий пакетов по 2 ядра
(Минимально 8 ядер на процессор; 16 ядер на сервер)

ЦПУ в сервере	Физических ядер в ЦПУ
	2	4	6	8	10
1	8	8	8	8	8
2	8	8	8	8	10
4	16	16	16	16	20
	Стоимости лицензий
	Требуются дополнительные лицензии

Стандартная редакция Windows Server 2016 может требовать дополнительного лицензирования.

Нано сервер новая выхолощенная (headless) опция установки только для 64-бит, которая устанавливает "минимально необходимую ОС", имеющую результатом отпечаток впечатляюще малых размеров, что имеет результатом большее время без простоев и меньшую поверхность для атак. Пользователи могут выбрать добавление ролей по мере необходимости, включая роли Hyper-V, горизонтально масштабируемого (scale out) Файлового сервера, сервера DNS и сервера IIS. Пользователь также может выбрать установку свойств, включающую поддержку Контейнера, Защитника (Defender), Кластеризации, Настроек желаемого состояния (DSC) Desired State Configuration, а также поддержку Экранированных (Shielded) ВМ.

В Windows Server 2016 Нано сервер доступен в:

Он поддерживает следующие встроенные роли и функции:

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

Hyper-V работает аналогичным образом на Нано сервере, включая всю обсуждаемую в данной книге функциональность, как это имеет место в Windows Server 2016, за исключением ряда предостережений:

Hyper-V Server 2016, свободно распространяемое решение виртуализации от Microsoft, имеет все включённые в Windows Server 2016 Hyper-V свойства, за исключением RemoteFX, другими словами, RDVH (Remote Desktop Virtualization Host, Хост виртуализации Удалённых рабочих мест) не поддерживается в свободно поставляемом сервере Hyper-V.

Единственная разница состоит в том, что Hyper-V Server Microsoft не содержит лицензий ВМ и какого- либо графического интерфейса. Управление должно осуществляться удалённо с применением PowerShell, Диспетчера Hyper-V с другого Windows Server 2016 или с Windows 10.

Все прочие свойства и ограничения Hyper-V в Windows Server 2016, включая Отказоустойчивый кластер (Failover Cluster), Миграция в реальном времени без совместного использования (Shared Nothing Live Migration), Дискретное назначение устройств (Discrete Device Assignment), и реплика Hyper-V (Hyper-V Replica) содержатся в свободно распространяемой версии Hyper-V.

В Windows 8 Microsoft впервые ввёл версию Клиента Hyper-V, причём его третья версия была запущена в Windows 10. Пользователи могут получать ту же самую практику, что и для Hyper-V Windows Server 2016 на своих рабочих местах и планшетах, что делает более простыми их сценарии тестирования и разработки.

Клиент Hyper-V в Windows 10 выходит за пределы простой виртуализации и помогает разработчикам Windows применять контейнеры, привнося Контейнеры Hyper-V в Windows 10. Это даёт ещё большую мощь в руки разработчиков для построения впечатляющих облачных приложений, получающих преимущества от естественных возможностей контейнеров в Windows.

Так как Контейнеры Windows используют свой собственный экземпляр ядра Windows, такой контейнер является реальным контейнером сервера во всём что простирается вплоть до его ядра. Помимо этого, при помощи гибкости контейнеров времени исполнения Windows (Контейнеров Windows Server или Контейнеров Hyper-V), построенные в Windows 10 контейнеры могут исполняться в Windows Server 2016 либо как Контейнеры Windows Server, либо как Контейнеры Hyper-V.

Также должна быть включена функция Hyper-V, так как Windows 10 поддерживает только контейнеры Hyper-V.

Клиент Hyper-V присутствует только в версии Windows 10 Pro или Enterprise и требует тех же свойств ЦПУ, что и Windows Server 2016, называемых SLAT (Second Level Address Translation, Трансляцией адресов второго уровня).

Хотя клиент Hyper-V очень похож на свою серверную версию, имеется ряд компонентов, которые присутствуют только в Windows Server 2016 Hyper-V. Вот перечень компонентов, которые вы можете обнаружить только в его серверной версии:

Даже при этих ограничениях Клиент Hyper-V имеет различные интересные свойства, такие как Миграция хранилища, VHDX, ВМ работающие с совместными ресурсами SMB 3.1, интегрированный PowerShell, Диспетчер Hyper-V, Расширяемый коммутатор Hyper-V, Контроль уровня обслуживания (QoS), Промышленные Контрольные точки, те же самые аппаратные ограничения на ВМ, что и у Windows Server 2016 Hyper-V, Динамическую память, Изменение размера памяти времени исполнения, Встроенную виртуализацию, Охранника DHCP, Зеркалирование порта, Именование устройства NIC и многое другое.

VMware является действующим конкурентом Hyper-V и текущая версия 6.5 предлагает VMware vSphere в качестве свободно распространяемого и автономно работающего Гипервизора, vSphere Standard, Enterprise и Enterprise Plus.

Приводимый ниже перечень сравнивает все свойства, имеющиеся в свободно распространяемой версии Hyper-V с VMware Sphere и Enterprise Plus:

Свойство	Windows Server 2012 R2	Windows Server 2016	VMware vSphere 6.5	VMware vSphere 6.5 Enterprise Plus
Логические процессоры	320	512	576	576
Физическая память	4ТБ	24ТБ	12ТБ	12ТБ
Виртуальные ЦПУ в хосте	2 048	2 048	4 096	4 096
Виртуальные ЦПУ на ВМ	64	240	8	128
Память на ВМ	1ТБ	12ТБ	6 128ГБ	6 128ГБ
Активные ВМ в хосте	1 024	1 024	1 024	1 024
Гостевой NUMA	Да	Да	Да	Да
Максимальное число узлов	64	64	Нет сведений	64
Максимальное число ВМ в кластере
ВМ с миграцией в реальном времени	8 000	8 000	Нет сведений	8 000
ВМ с миграцией в реальном времени с компрессией	Да	Да	Нет	Да
ВМ с миграцией в реальном времени и применением RDMA	Да	Да	Нет сведений	Нет
Одновременная миграция в реальном времени при 1GbE	Без ограничений	Без ограничений	Нет сведений	4
Одновременная миграция в реальном времени при 10GbE	Без ограничений	Без ограничений	Нет сведений	8
Миграция хранилища в реальном времени	Да	Да	Нет	Да
Миграция в реальном времени без совместного использования	Да	Да	Нет	Да
Накатываемые на кластер обновления	Да	Да	Нет сведений	Да
Реплика ВМ в горячем режиме/ Добавление виртуального диска	Да	Да	Нет сведений	Нет
Встроенная поддержка 4-кБ диска	Да	Да	Нет	Нет
Максимальный размер Виртуального диска	64ТБ	64ТБ	2ТБ	62ТБ
Максимальный размер Пробрасываемого диска	256ТБ+	256ТБ+	64ТБ	64ТБ
Расширяемый сетевой коммутатор	Да	Да	Нет	Сторонних производителей
Сетевая виртуализация	Да	Да	Нет	Требует сети vCloud и безопасности
Разгрузка задач IPsec	Да	Да	Нет	Нет
SR-IOV Виртуальные NIC в ВМ Именование устройств NIC ВМ	Да 12 Нет	Да 12 Нет	Нет сведений 10 Нет сведений	Нет 10 Нет
Мониторинг приложений гостевой ОС	Да	Да	Нет	Нет
Гостевая кластеризация с миграцией в реальном времени	Да	Да	Нет сведений	Нет
Гостевая кластеризация с Динамической памятью	Да	Да	Нет сведений	Нет
Экранированные ВМ	Нет	Да	Нет сведений	Нет
DDA - проброс GPU	Нет	Да	Да	Да

AVMA (Automatic Virtual Machine Activation, Автоматическая активация Виртуальной машины) является функция, которая была введена в Windows Server 2012 R2. AVMA связывает необходимую активацию ВМ с виртуальным сервером лицензий и активирует все ВМ при их запуске. Это избавляет от необходимости ввода информации о лицензировании и активирует каждую ВМ индивидуально.

Чтобы получить преимущества данной функциональности, AVMA требует чтобы ваш хост применял Windows Server 2012 R2 Datacenter или более позднюю версию и чтобы такая ОС гостевой виртуальной машины была бы либо Windows Server 2012 R2 Datacenter, либо Windows Server 2012 R2 Standard, или более поздних версий.

Ото процесс осуществляемый за один шаг. Когда хост Hyper-V активирован и исполняются все гостевые ВМ (естественно без активации), единственный остающийся шаг состоит в у становке необходимого ключа AVMA на таких гостевых ВМ (Datacenter или Standard). Чтобы установить данный ключ вручную при помощи командной строки, воспользуйтесь, пожалуйста, следующим синтаксисом в поднимаемой внутри такой гостевой ОС командной строке:

C:\>slmgr.vbs /ipk <AVMA Key>
 	   

Вот общедоступные ключи AVMA которые можно применять для Windows Server 2012 R2.

Редакция	Ключ AVMA
Datacenter	Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW
Standard	DBGBW-NPF86-BJVTX-K3WKJ-MTB6V
Essential	K2XGM-NMBT3-2R6Q8-WF2FK-P36R2

Вот общедоступные ключи AVMA которые можно применять для Windows Server 2016.

Редакция	Ключ AVMA
Datacenter	TMJ3Y-NTRTM-FJYXT-T22BY-CWG3J
Standard	C3RCX-M6NRP-6CXC9-TW2F2-4RHYD
Essential	B4YNW-62DX9-W8V6M-82649-MHBKQ

Весь этот процесс не требует сетевого соединения или выхода в Интернет какого- либо вида между данным хостом и данным гостем.

Для лучшего понимания технологий Hyper-V следующая, созданная Мистером Беном Армстронгом (Главным управляющим программы в команде Hyper-V), таблица иллюстрирует все сценарии, где могут применяться конфликтные свойства Hyper-V: