Автоматическая активация виртуальной машины Automatic virtual machine activation

Относится к: Windows Server 2019, Semi-Annual Channel для Windows Server, Windows Server 2016, Windows Server 2012 R2 Applies to: Windows Server 2019, Windows Server Semi-Annual Channel, Windows Server 2016, Windows Server 2012 R2

Автоматическая активация виртуальной машины (AVMA) — это механизм подтверждения законности приобретения, помогающий удостовериться, что продукты Windows используются в соответствии с правами на использование продуктов и условиями лицензионного соглашения на использование программного обеспечения корпорации Майкрософт. Automatic Virtual Machine Activation (AVMA) acts as a proof-of-purchase mechanism, helping to ensure that Windows products are used in accordance with the Product Use Rights and Microsoft Software License Terms.

AVMA позволяет устанавливать виртуальные машины на сервере с должным образом активированной ОС Windows, не настраивая ключи продукта для каждой виртуальной машины, даже в отключенных средах. AVMA lets you install virtual machines on a properly activated Windows server without having to manage product keys for each individual virtual machine, even in disconnected environments. Она привязывает активацию виртуальной машины к лицензированному серверу виртуализации и активирует виртуальную машину при запуске. AVMA binds the virtual machine activation to the licensed virtualization server and activates the virtual machine when it starts up. AVMA также предоставляет отчеты по использованию в реальном времени и данные о состоянии лицензии виртуальной машины за прошлые периоды. AVMA also provides real-time reporting on usage and historical data on the license state of the virtual machine. Отчеты и данные отслеживания доступны на сервере виртуализации. Reporting and tracking data is available on the virtualization server.

Практическое применение Practical applications

AVMA предоставляет ряд преимуществ на серверах виртуализации, активированных с использованием корпоративного лицензирования или лицензирования OEM. On virtualization servers that are activated using Volume Licensing or OEM licensing, AVMA offers several benefits.

Администраторы серверов в центрах обработки данных могут использовать AVMA для выполнения следующих действий: Server datacenter managers can use AVMA to do the following:

Активация виртуальных машин в удаленных расположениях Activate virtual machines in remote locations

Активация виртуальных машин с подключением к Интернету или без него Activate virtual machines with or without an internet connection

Отслеживание данных об использовании и лицензиях виртуальных машин с сервера виртуализации без прав доступа к виртуализованным системам Track virtual machine usage and licenses from the virtualization server, without requiring any access rights on the virtualized systems

Не требуется управлять ключами продукта и читать наклейки на серверах. There are no product keys to manage and no stickers on the servers to read. Виртуальная машина активируется и продолжает работать даже при переносе в массиве серверов виртуализации. The virtual machine is activated and continues to work even when it is migrated across an array of virtualization servers.

Партнеры с лицензионным соглашением с поставщиком услуг (SPLA) и другие поставщики услуг размещения не обязаны предоставлять ключи продукта арендаторам или активировать виртуальные машины арендаторов. Service Provider License Agreement (SPLA) partners and other hosting providers do not have to share product keys with tenants or access a tenant’s virtual machine to activate it. С помощью AVMA клиенты могут легко активировать виртуальные машины. Virtual machine activation is transparent to the tenant when AVMA is used. Поставщики услуг размещения могут использовать журналы сервера для проверки соответствия лицензии и отслеживания хронологии использования клиента. Hosting providers can use the server logs to verify license compliance and to track client usage history.

Системные требования System requirements

Для AVMA требуется Microsoft Virtualization Server с Windows Server 2019 Datacenter, Windows Server 2016 Datacenter или Windows Server 2012 R2. AVMA requires a Microsoft Virtualization Server running Windows Server 2019 Datacenter, Windows Server 2016 Datacenter, or Windows Server 2012 R2.

Ниже представлен список гостей, которых можно активировать с помощью различных версий серверов узла. Here are the guests that the different version hosts can activate:

Версия сервера узла Server host version	Windows Server 2019 Windows Server 2019	Windows Server 2016 Windows Server 2016	Windows Server 2012 R2 Windows Server 2012 R2
Windows Server 2019 Windows Server 2019	X X	X X	X X
Windows Server 2016 Windows Server 2016	X X	X X
Windows Server 2012 R2 Windows Server 2012 R2	X X

Обратите внимание на то, что они активируют все выпуски (Datacenter, Standard и Essentials). Note that these activate all editions (Datacenter, Standard, or Essentials).

Это средство не работает с другими технологиями виртуализации сервера. This tool does not work with other Virtualization Server technologies.

Реализация AVMA How to implement AVMA

На сервере виртуализации Windows Server Datacenter установите и настройте роль Microsoft Hyper-V Server. On a Windows Server Datacenter virtualization server, install and configure the Microsoft Hyper-V Server role. Дополнительную информацию см. в статье об установке Hyper-V Server. For more information, see Install Hyper-V Server.

Создайте виртуальную машину и установите на ней поддерживаемую серверную операционную систему. Create a virtual machine and install a supported server operating system on it.

Установите ключ AVMA на виртуальной машине. Install the AVMA key in the virtual machine. В командной строке с повышенными привилегиями введите следующую команду: From an elevated command prompt, run the following command:

Виртуальная машина автоматически активирует лицензию в соответствии с сервером виртуализации. The virtual machine will automatically activate the license against the virtualization server.

Можно также использовать ключи AVMA в любом файле установки Unattend.exe. You can also employ the AVMA keys in any Unattend.exe setup file.

Ключи AVMA AVMA keys

Перечисленные ниже ключи AVMA можно использовать для Windows Server 2019. The following AVMA keys can be used for Windows Server 2019.

Выпуск Edition	Ключ AVMA AVMA key
Datacenter Datacenter	H3RNG-8C32Q-Q8FRX-6TDXV-WMBMW H3RNG-8C32Q-Q8FRX-6TDXV-WMBMW
Standard Standard	TNK62-RXVTB-4P47B-2D623-4GF74 TNK62-RXVTB-4P47B-2D623-4GF74
Essentials Essentials	2CTP7-NHT64-BP62M-FV6GG-HFV28 2CTP7-NHT64-BP62M-FV6GG-HFV28

Перечисленные ниже ключи AVMA можно использовать для Windows Server версий 1909, 1903 и 1809. The following AVMA keys can be used for Windows Server, versions 1909, 1903, and 1809.

Выпуск Edition	Ключ AVMA AVMA key
Datacenter Datacenter	H3RNG-8C32Q-Q8FRX-6TDXV-WMBMW H3RNG-8C32Q-Q8FRX-6TDXV-WMBMW
Standard Standard	TNK62-RXVTB-4P47B-2D623-4GF74 TNK62-RXVTB-4P47B-2D623-4GF74

Перечисленные ниже ключи AVMA можно использовать для Windows Server версии 1803 и 1709. The following AVMA keys can be used for Windows Server, version 1803 and 1709.

Выпуск Edition	Ключ AVMA AVMA key
Datacenter Datacenter	TMJ3Y-NTRTM-FJYXT-T22BY-CWG3J TMJ3Y-NTRTM-FJYXT-T22BY-CWG3J
Standard Standard	C3RCX-M6NRP-6CXC9-TW2F2-4RHYD C3RCX-M6NRP-6CXC9-TW2F2-4RHYD

Перечисленные ниже ключи AVMA можно использовать для Windows Server 2016. The following AVMA keys can be used for Windows Server 2016.

Выпуск Edition	Ключ AVMA AVMA key
Datacenter Datacenter	TMJ3Y-NTRTM-FJYXT-T22BY-CWG3J TMJ3Y-NTRTM-FJYXT-T22BY-CWG3J
Standard Standard	C3RCX-M6NRP-6CXC9-TW2F2-4RHYD C3RCX-M6NRP-6CXC9-TW2F2-4RHYD
Essentials Essentials	B4YNW-62DX9-W8V6M-82649-MHBKQ B4YNW-62DX9-W8V6M-82649-MHBKQ

Перечисленные ниже ключи AVMA можно использовать для Windows Server 2012 R2. The following AVMA keys can be used for Windows Server 2012 R2.

Выпуск Edition	Ключ AVMA AVMA key
Datacenter Datacenter	Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW
Standard Standard	DBGBW-NPF86-BJVTX-K3WKJ-MTB6V DBGBW-NPF86-BJVTX-K3WKJ-MTB6V
Essentials Essentials	K2XGM-NMBT3-2R6Q8-WF2FK-P36R2 K2XGM-NMBT3-2R6Q8-WF2FK-P36R2

Отчетность и отслеживание Reporting and tracking

Реестр (KVP) на сервере виртуализации предоставляет данные по отслеживанию в реальном времени для операционных систем на виртуальной машине. The registry (KVP) on the virtualization server provides real-time tracking data for the guest operating systems. Поскольку раздел реестра перемещается вместе с виртуальной машиной, можно также получить информацию о лицензии. Because the registry key moves with the virtual machine, you can get license information as well. По умолчанию KVP возвращает данные о виртуальной машине, в том числе: By default the KVP returns information about the virtual machine, including the following:

Полное доменное имя Fully qualified domain name

Операционную систему и установленные пакеты обновления Operating system and service packs installed

Архитектуру процессора Processor architecture

Сетевые адреса IPv4 и IPv6 IPv4 and IPv6 network addresses

Адреса RDP RDP addresses

Дополнительные сведения о том, как получить эту информацию, см. в публикации Hyper-V Script: Looking at KVP GuestIntrinsicExchangeItems (GuestIntrinsicExchangeItems KVP в скрипте Hyper-V). For more information about how to get this information, see Hyper-V Script: Looking at KVP GuestIntrinsicExchangeItems.

Данные KVP не защищены. KVP data is not secured. Они допускают модификации и не контролируются на предмет изменений. It can be modified and is not monitored for changes.

Данные KVP следует удалить в случае замены ключа AVMA другим ключом продукта (розничным, OEM или ключом корпоративного лицензирования). KVP data should be removed if the AVMA key is replaced with another product key (retail, OEM, or volume licensing key).

Данные о запросах AVMA за прошлые периоды доступны в файле журнала на сервере виртуализации (EventID 12310). Historical data about AVMA requests is available in a log file on the virtualization server (EventID 12310).

Поскольку процесс активации AVMA прозрачен, сообщения об ошибках не отображаются. Since the AVMA activation process is transparent, error messages are not displayed. Однако данные о перечисленных ниже событиях записываются в файл журнала на виртуальных машинах (EventID 12309). However, the following events are captured in a log file on the virtual machines (EventID 12309).

Windows Server 2019 — роль Hyper-V

На сервере Windows Server 2019 потребовалось запустить виртуальную машину посредством Hyper-V. Установим роль Hyper-V на сервер Windows Server 2019 и создадим какую-нибудь виртуальную машину.

Я буду все действия выполнять на свежем сервере Windows Server 2019 Standard Evaluation. Сервер развёрнут на гипервизоре VMware ESXi. Да-да, я понимаю, что на виртуалке поднимать систему виртуализации не самая здравая идея, но всё это в тестовых целях.

Установка роли Hyper-V на сервере Windows Server 2019

Открываем Server Manager. Manage > Add Roles and Features

Открывается мастер установки ролей. Попадаем в раздел Before You Begin.

Это информационная страница, Next.

Попадаем в раздел Installation Type. Здесь нужно выбрать тип установку. Выбираем «Role-based or feature-based installation». Next.

Попадаем в раздел Server Selection. Здесь нужно выбрать сервер, на который будем устанавливать роль. Я выбираю текущий сервер. Next.

Попадаем в раздел Server Roles. Находим роль Hyper-V, выделяем галкой. Нам предлагают установить фичи, которые необходимы для работы Hyper-V, соглашаемся. Add Features.

Облом. Я словил ошибку:

Hyper-V cannot be installed: The processor does not have required virtualization.

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

• Intel — Intel Virtualization Technology
• AMD — SVM Mode

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

В настройках CPU включаю галку «Expose hardware assisted virtualization to the guest OS».

Включаю сервер. Снова проходим ту же процедуру. Открываем Server Manager. Manage > Add Roles and Features. Выбираем «Role-based or feature-based installation». Находим роль Hyper-V, выделяем галкой. Нам предлагают установить фичи, которые необходимы для работы Hyper-V, соглашаемся. Add Features.

В этот раз всё проходит успешно. Next.

Попадаем в раздел Features, здесь нам ничего не нужно. Next.

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

• Перед установкой роли Hyper-V следует решить, какую сетевую карту сервера вы будете подключать к виртуальному коммутатору.
• После установки роли Hyper-V для управления виртуальными машинами используйте Hyper-V Manager.

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

Попадаем в раздел Migration. Здесь настраивается миграция виртуальных машин. У меня будет один сервер с Hyper-V, поэтому никаких миграций не предусмотрено. Next.

Попадаем в раздел Default Stores. Здесь можно настроить папки по умолчанию для хранения виртуальных дисков и файлов настроек виртуальных машин. Next.

Попадаем в раздел Confirmation. Проверяем что у нас будет установлено. Здесь же ставим галку, чтобы сервер при необходимости перезагрузился. Install.

Начинается процесс установки роли Hyper-V.

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

Установка роли Hyper-V успешно завершена. Close.

В Administrative Tools появляется Hyper-V Manager.

Настройка виртуального коммутатора Hyper-V

Запускаем Hyper-V Manager.

В списках серверов Hyper-V есть текущий сервер ILAB-DC. Нажимаем на него.

Список виртуальных машин пуст. Перед созданием новой виртуалки нужно настроить виртуальный коммутатор. По идее он уже должен быть настроен, т.к. мы при установке роли Hyper-V ставили галку для привязки виртуального коммутатора к физическому сетевому адаптеру. Но проверить не помешает, были случаи, когда виртуальный коммутатор на привязывался к физическому адаптеру. Такое случается, когда роль Hyper-V устанавливается несколько раз. В этом случае зайдите в настройки физического адаптера и снимите галку со всего где есть слово «Hyper-V», после этого физический адаптер можно снова привязать к виртуальному коммутатору из оснастки Hyper-V Manager.

Нажимаем Virtual Switch Manager.

У меня один виртуальный коммутатор «vmxnet3 Ethernet Adapter — Virtual Switch». Виртуальный коммутатор может работать в трёх режимах:

• External network
  Предоставляет виртуальным машинам доступ к физической сети для взаимодействия с серверами и клиентами во внешней сети. Позволяет виртуальным машинам на одном сервере Hyper-V взаимодействовать друг с другом.
  • Allow management operating system to share this network adapter (Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру)
    Выберите этот параметр, если вы хотите разрешить узлу Hyper-V совместно использовать виртуальный коммутатор и сетевую карту или группу сетевых адаптеров с виртуальной машиной. Если этот параметр включен, узел может использовать любые параметры, настроенные для виртуального коммутатора, такие как параметры качества обслуживания (QoS), параметры безопасности или другие функции виртуального коммутатора Hyper-V.
  • Enable single-root I/O virtualization (SR-IOV) (Включить виртуализацию SR-IOV)
    Выберите этот параметр, только если вы хотите разрешить трафику виртуальной машины обходить коммутатор виртуальной машины и перейти непосредственно к физическому сетевому адаптеру. Сетевой адаптер должен поддерживать SR-IOV.
• Internal network
  Разрешает обмен данными между виртуальными машинами на одном сервере Hyper-V, а также между виртуальными машинами и сервером Hyper-V.
• Private network
  Разрешает обмен данными только между виртуальными машинами на одном сервере Hyper-V. Частная сеть изолирована от всего внешнего сетевого трафика на сервере Hyper-V. Этот тип сети полезен, если необходимо создать изолированную сетевую среду, например изолированный тестовый домен.

SR-IOV (Single Root Input/Output Virtualization, виртуализация ввода-вывода с единым корнем) — технология виртуализации устройств, позволяющая предоставить виртуальным машинам прямой доступ к части аппаратных возможностей устройства.

При необходимости можно включить поддержку VLAN.

Настраиваю виртуальный коммутатор, вернее, ничего не меняю, меня устраивают текущие настройки. OK.

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

Пришло время создать первую виртуальную машину. Открываем Hyper-V Manager.

New > Virtual Machine.

Открывается мастер создания виртуальных машин. Попадаем в раздел Before You Begin. Здесь нет ничего интересного. Next.

Попадаем в раздел Specify Name and Location. Указываем имя виртуалки. При необходимости можно изменить папку, в которой будут храниться файлы виртуалки. Next.

Попадаем в раздел Specify Generation. Выбор поколения зависит от того, какую операционную систему на виртуальной машине вы хотите установить, и метод загрузки, который вы хотите использовать для развертывания виртуальной машины. Виртуальные машины поколения 1 поддерживают большинство гостевых операционных систем. Виртуальные машины поколения 2 поддерживают большинство 64-разрядных версий Windows, Linux и FreeBSD. Рекомендуется выбрать поколение 2 за исключением случаев когда:

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

Попадаем в раздел Assign Memory. Выделяем память для виртуалки. Динамическая память забирается у сервера, как ни странно, динамически, т.е. сколько нужно, столько и забирается. Если галку не поставить, то вся выбранная память серверу будет недоступна. Next.

Попадаем в раздел Configure Networking. Выбираем виртуальный коммутатор. У меня он один. Next.

Попадаем в раздел Connect Virtual Hard Disk. Здесь создаём жёсткий диск, можно выбрать папку для его хранения. Можно подключить существующий жёсткий диск. Можно не подключать жёсткий диск. Я создаю новый диск объёмом 40 ГБ. Next.

Попадаем в раздел Installation Options. Здесь можно примонтировать образ установочного диска, я сделаю это позже. Next.

Попадаем в раздел Summary. Проверяем параметры. Finish.

Начинается процесс создания виртуальной машины.

Виртуальная машина создана, она выключена (State = Off).

Установка операционной системы на виртуальную машину Hyper-V

Теперь примонтируем ISO образ к виртуальной машине и попробуем начать процесс установки операционной системы.

Выделяем виртуалку, нажимаем Settings.

Переходим в раздел SCSI Controller. Видим, что в нём находится только жёсткий диск. Справа выбираем DVD Drive, Add.

У виртуальной машины появляется виртуальный DVD Drive. Выбираем Image file, выбираем ISO образ для установки операционной системы. Apply.

Правой кнопкой на виртуалку, Connect.

Открывается консоль виртуалки. ISO образ можно также вставить/извлечь в меню Mediz > DVD Drive. Включаем виртуалку, Start.

Виртуальная машина включается.

Загружается ISO образ и мы можем установить операционную систему, дальше вы справитесь.

Заключение

Мы с вами на сервере Windows Server 2019 установили роль Hyper-V, настроили виртуальный коммутатор и создали первую виртуальную машину. Подключили виртуальный дисковод и загрузились с установочного ISO образа операционной системы.

Добро пожаловать в волшебный мир виртуализации Hyper-V.