Windows лицензия на виртуальную машину

Лицензирование Windows Server в виртуальной среде

В этой статье мы рассмотрим особенности лицензирования операционной системы Windows Server 2019, 2016 и 2012 R2 с точки зрения новой модели лицензирования Microsoft. Также мы рассмотрим правила и порядок лицензирования при использовании Windows Server в качестве гостевой ОС в виртуальных машинах, в том числе в кластерах с поддержкой возможности миграции виртуальных машин между гипервизорами (технологии VMWare VMotion, Hyper-V Live Migration и т.п.).

Начиная с Windows Server 2012 Microsoft стала кардинально менять и, самое главное, упрощать модель лицензирования своей серверной платформы с учетом современных реалий широкого использования виртуализации.

Редакции WindowsServer

В большинстве случаев при обсуждении модели лицензирования целесообразно рассматривать Standard и Datacenter редакции Windows Server.

В Windows Server 2012 R2 функционал редакций Standard и Datacenter практически идентичен за исключением лицензионных прав на запуск виртуальных машин. Это означает, что необходимую редакцию нужно выбирать, основываясь только на количестве виртуальных машин на физическом хосте (сервере), а не от наличия/отсутствия необходимого функционала.

В Windows Server 2012 R2 Standard – лицензия позволяет запустить не более двух виртуальных машин;
В Windows Server 2012 R2 Datacenter – на одном физическом хосте с этой лицензией можно запустить неограниченное количество виртуальных машин (напомним, что такие виртуальные машины можно активировать по упрощенной схеме с помощью функции автоматической активации виртуальных машин — AVMA).

По сути, при выборе редакции Windows Server 2012 R2 нужно в первую очередь основываться на том нужна, или не нужна вам виртуализация.

Лицензия Windows Server 2016/2019 Standard позволяет вам запустить до двух ВМ с Windows Server на одном физическом хосте.

В Windows Server 2016 и 2019 в редакции Datacenter поддерживаются ряд полезных технологий, которые полезны при широком использовании возможностей виртуализации и интеграции в облако Azure. Например, в редакции WS 2016 Datacenter поддерживаются:

Лицензирование процессоров в Windows Server 2012 R2

В Windows Server 2012 R2 – одна лицензия позволяла запускать ОС на одном одно- или двух-процессорном сервере. Т.е одна лицензия покрывает до двух процессоров (сокетов), расположенных в одном физическом сервере (ядра процессорами не являются!). Нельзя разделить одну лицензию на два однопроцессорных сервера (в этом случае придется приобрести две лицензии Windows Server). Например, если в одном физическом сервере установлено более двух процессоров, нужно купить по 1 лицензии на каждую пару процессов. Так, например, для 4-х процессорного сервера, понадобится 2 лицензии Windows Server 2012 R2.

Лицензирование ядер в Windows Server 2016 и 2019

В Windows Server 2016 и Windows Server 2019 Microsoft перешла от модели лицензирования физических процессоров на модель лицензирования ядер (Core-based). Это связано с тенденцией производителей CPU и серверов наращивать не количество процессоров, а количество ядер на одном процессоре и нежеланием Microsoft лишаться прибыли при массовом использовании многоядерных серверов. Особенности лицензирования современных версий Windows Server 2016 и 2019 (подробно рассматривается в этой статье):

1 лицензия Windows Server 2016 позволяет лицензировать 2 физических ядра сервера (т.е. Microsoft продает двух ядерные лицензии);
Стоимость одной 2-x ядерной лицензии в 8 раз снижена по сравнению с одной процессорной лицензией для Windows Server 2012 R Но на физический сервер нужно приобрести минимум 8 таких лицензий (на 16 ядер) – это минимальный пакет на 1 сервер. Таким образом стоимость лицензирования одного физического 2-х процессорного сервера с количеством ядер на CPU до 8 не изменилась;

Лицензирование виртуальных машин в WindowsServer

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

Например, у вас имеется двух процессорный сервер с 16 ядрами. Если приобрели 8 лицензий Windows Server 2019 Standard и лицензировали вся физический ядра сервера. Это значит, вы имеете право запускать до 2 ВМ с Windows Server на лицензированном физическом хосте. Лицензия Datacenter позволяет запустить на лицензированном хосте неограниченное количество виртуальных ОС.

Что делать, если на сервере с лицензией Standard вам понадобится запустить более двух виртуальных машин? Вам придется приобрести нужное количество лицензий исходя из следующего соображения: одна лицензия Standard позволяет запустить 2 виртуальные машины.

Например, вы хотите лицензировать двухпроцессорный (по 8 ядер на каждом) сервер с четырьмя виртуальными машинами. В модели лицензирования ядер в Windows Server 2016 Standard вам нужно приобрести 16 двухъядерных лицензий Window Server Standard ( 2 комплекта лицензий, закрывающих физические ядра) или 8 двухъядерных лицензий Datacenter (как сменить редакцию Windows Server на более высокую без переустановки).

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

На основании текущих прайсов Microsoft на Windows Server можно сделать вывод, что покупка редакции Datacenter экономически выгодна, если на одном физическом хосте вы планируете запустить более 14 виртуальных машин. Если количество ВМ меньшее, выгоднее приобрести несколько лицензий Standard, закрывающих ваши потребности по ядрам и виртуальным машинам.

Если вы используете виртуализацию на своем физическом сервере с Windows Server 2016, вы можете использовать хостовую ОС только для обслуживания и управления роли Hyper-V и виртуальных машин. Т.е. вы не сможете установить на физический сервер Windows Server 2016, запустить на нем две ВМ и получить три полноценных сервера под свои задачи. В терминологии Microsoft физической инстанс ОС называется POSE (physical operating system environment), а виртуальные – VOSE (virtual operating system
environment).

Лицензирование Windows Server с учетом возможности миграции виртуальных машин между физическими серверами

Далее рассмотрим особенности лицензирования в том случае, если виртуальная машина с Windows Server ОС может перемещаться между физическими серверами в ферме виртуализации (с помощью VMWare VMotion, Hyper-V Live Migration и т.п.).

Для большинства серверных продуктов Microsoft покупка Software Assurance (SA) предоставляет право переносить лицензию между физическими хостами. Но Windows Server является исключением из этого правила. Согласно условиям лицензионного соглашения, лицензию между хостами можно переносить не чаще чем 1 раз в 90 дней.

Как же лицензировать ферму их нескольких физических хостов с гипервизорами, в которой ВМ могут перемещаться между серверами? В такой схеме вам придется на каждый физический сервер приобрести количество лицензии, покрывающее максимальное количество виртуальных машин, которые могут быть запущены на нем в любой момент времени (с учетом ситуации, когда все виртуальные машины фермы «соберутся» на одном хосте). Т.е. лицензии на виртуальные машины привязаны к физическому хосту и не переезжают между хостами вместе с ВМ.

Например, для двух отдельно стоящих двух-процессорных физических серверов с двумя ВМ на каждом вам понадобятся 2×8 лицензии Windows Server Standard.

То в случае, если виртуальные машины могут мигрировать между этими же серверами, нам понадобится еще 2×8 лицензии (из расчета что на каждом сервере одновременно могут быть запущены сразу 4 ВМ).

В случае с редакцией Datacenter на каждый физический хост будет достаточно по одному комплекту лицензии, закрывающей все ядра (в минимальной конфигурации 8 двухъядерных лицензий Datacenter), т.к. такая лицензия позволяет запустить неограниченное количество ВМ.

Таким образом вы должны выбирать наиболее выгодный тип лицензии следует в зависимости от планируемого количества ВМ в ферме.

Примеры расчета лицензий Windows Server для виртуализации

Ниже приведены несколько примеров расчета лицензий Windows Server на физические сервера при использовании виртуализации.

Пример 1. Имеется Hyper-V кластер из 5 серверов. На каждом 2 процессора по 20 ядер. На каждом будут работать 10 виртуальных машин.

Т.к. 5 серверов объединены в HA кластер Hyper-V, значит потенциально на каждом хосте при миграции оказаться могут 50 виртуальных машин. Соответственно, выгоднее приобрести лицензии Datacenter.

Количество лицензий на 1 сервер:

Общее кол-во ядер – 40
Количество 2 ядерных лицензий (WinSvrDCCore 2019 SNGL OLP 2Lic NL CoreLic) – 20

Общее кол-во 2 ядерных лицензий WinSvrDCCore на 5 серверов – 100.

Пример 2. В филиале установлен 1 сервер с 2 сокетами по 4 ядра, на котором запущено 4 виртуальных машины. Сколько лицензий Windows Server нужно приобрести?

На сервере имеется 8 ядер. Согласно условиям лицензирования – вам нужно покрыть минимум 16 ядер. Значит вам нужно купить 8 лицензий Windows Server 2016 (WinSvrSTDCore 2 Core). Это позволит запустить 2 ВМ. Чтобы запустить еще 2 ВМ нужно купить еще один комплект лицензий для ядер.

Таким образом для лицензирования нужно 16 2-х ядерных лицензий Windows Server (WinSvrSTDCore 2019 SNGL OLP 2Lic NL CoreLic) или 2 16-ядерные лицензии (WinSvrSTDCore 2019 SNGL OLP 16Lic NL CoreLic).

Источник

Настройка VDA для активации подписки Windows 10 Configure VDA for Windows 10 Subscription Activation

В этом документе описывается настройка виртуальных машин (ВМ), чтобы включить активацию подписки Windows 10 для виртуального рабочего стола Windows (VDA). This document describes how to configure virtual machines (VMs) to enable Windows 10 Subscription Activation in a Windows Virtual Desktop Access (VDA) scenario. Windows VDA — это устройство или пользовательский механизм лицензирования для управления доступом к виртуальным рабочим столам. Windows VDA is a device or user-based licensing mechanism for managing access to virtual desktops.

Инструкции по развертыванию предоставляются для следующих сценариев. Deployment instructions are provided for the following scenarios:

Требования Requirements

Виртуальные машины должны работать под управлением Windows 10 Pro версии 1703 (также известной как Creators Update) или более поздней версии. VMs must be running Windows 10 Pro, version 1703 (also known as the Creator’s Update) or later.
Виртуальные машины должны быть присоединены к службе каталогов Active Directory или Azure Active Directory (AAD). VMs must be Active Directory-joined or Azure Active Directory (AAD)-joined.
Виртуальные машины должны быть 1 поколения. VMs must be generation 1.
Виртуальные машины должны размещаться у соответствующего мультитенантного поставщика услуг размещения (QMTH). VMs must hosted by a Qualified Multitenant Hoster (QMTH).

Активация Activation

Сценарий 1 Scenario 1

Виртуальная машина работает под управлением Windows 10 версии 1803 или более поздней. The VM is running Windows 10, version 1803 or later.

Виртуальная машина размещена в Azure или другом полном хост-клиенте (QMTH). The VM is hosted in Azure or another Qualified Multitenant Hoster (QMTH).

Если пользователь с правами VDA входит в виртуальную машину с использованием учетных данных AAD, виртуальный компьютер автоматически пошаговая отладка в масштабах предприятия и активирована. When a user with VDA rights signs in to the VM using their AAD credentials, the VM is automatically stepped-up to Enterprise and activated. Не нужно выполнять активацию Windows 10 Pro. There is no need to perform Windows 10 Pro activation. Это избавляет от необходимости поддерживать службы KMS и MAK в подпадающей облачной инфраструктуре. This eliminates the need to maintain KMS or MAK in the qualifying cloud infrastructure.

Сценарий 2 Scenario 2

Узел Hyper-V и виртуальная машина работают под управлением Windows 10 версии 1803 или более поздней. The Hyper-V host and the VM are both running Windows 10, version 1803 or later.

Включена унаследованная активация . Inherited Activation is enabled. Все виртуальные машины, созданные пользователем с лицензией на Windows 10 E3 или для вододействия, автоматически активируются независимо от того, входит ли пользователь в систему с помощью локальной учетной записи или с помощью учетной записи Azure Active Directory. All VMs created by a user with a Windows 10 E3 or E5 license are automatically activated independent of whether a user signs in with a local account or using an Azure Active Directory account.

Сценарий 3 Scenario 3

Виртуальная машина работает под управлением Windows 10 версии 1703 или 1709 или не является уполномоченным партнером QMTH . The VM is running Windows 10, version 1703 or 1709, or the hoster is not an authorized QMTH partner.

В этой ситуации базовая лицензия на Windows 10 Pro должна быть активирована перед активацией подписки Windows 10 Корпоративная. In this scenario, the underlying Windows 10 Pro license must be activated prior to Subscription Activation of Windows 10 Enterprise. Активация осуществляется с помощью универсального ключа корпоративного лицензирования Windows 10 Pro (GVLK) и сервера активации для корпоративной лицензии, предоставляемого ведущим приложением. Activation is accomplished using a Windows 10 Pro Generic Volume License Key (GVLK) and a Volume License KMS activation server provided by the hoster. В качестве альтернативного варианта можно использовать сервера активации KMS в вашей корпоративной сети, если вы настроили закрытое подключение, например ExpressRoute или шлюз VPN. Alternatively, a KMS activation server on your corporate network can be used if you have configured a private connection, such as ExpressRoute or VPN Gateway.

Примеры проблем активации см. в разделе Устранение проблем при взаимодействии с пользователем. For examples of activation issues, see Troubleshoot the user experience.

Виртуальные машины, присоединенные к Active Directory Active Directory-joined VMs

Используйте следующие инструкции для подготовки виртуальной Машины для Azure: Подготовьте виртуальный жесткий диск Windows или VHDX, чтобы загрузить Azure Use the following instructions to prepare the VM for Azure: Prepare a Windows VHD or VHDX to upload to Azure

(Необязательно) Чтобы отключить проверку подлинности на сетевом уровне, введите следующее в командной строке с повышенными привилегиями: (Optional) To disable network level authentication, type the following at an elevated command prompt:

В командной строке с повышенными привилегиями введите команду sysdm.cpl и нажмите клавишу ВВОД. At an elevated command prompt, type sysdm.cpl and press ENTER.

На вкладке «Удаленный доступ» выберите разрешить удаленные подключения к этому компьютеру и нажмите кнопку Выбрать пользователей. On the Remote tab, choose Allow remote connections to this computer and then click Select Users.

Щелкните Добавить, введите Прошедшие проверку подлинности пользователи, а затем трижды нажмите кнопку ОК. Click Add, type Authenticated users, and then click OK three times.

Следуйте инструкциям по использованию средства sysprep в разделе Шаги для подготовки виртуального жесткого диска, а затем снова запустите виртуальную машину. Follow the instructions to use sysprep at Steps to generalize a VHD and then start the VM again.

Если вы хотите активировать Windows 10 Pro так, как описано в сценарии 3, выполните указанные ниже действия, чтобы использовать конструктор конфигураций Windows и вставить ключ активации. If you must activate Windows 10 Pro as described for scenario 3, complete the following steps to use Windows Configuration Designer and inject an activation key. В противном случае перейдите к действию 20. Otherwise, skip to step 20.

Откройте конструктор конфигураций Windows и нажмите кнопку Службы подготовки рабочего стола. Open Windows Configuration Designer and click Provison desktop services.

В разделе имя введите Desktop AD Enrollment Pro GVLK, нажмите кнопку Готовои затем на странице Настройка устройства введите имя устройства. Under Name, type Desktop AD Enrollment Pro GVLK, click Finish, and then on the Set up device page enter a device name. — Примечание: вы можете использовать другое имя проекта, однако это имя также используется с dism.exe на последующем этапе. Note: You can use a different project name, but this name is also used with dism.exe in a subsequent step.

В разделе Введите ключ продукта введите ключ Pro GVLK: W269N-WFGWX-YVC9B-4J6C9-T83GX. Under Enter product key type the Pro GVLK key: W269N-WFGWX-YVC9B-4J6C9-T83GX.

На странице Настройка сети выберите отключение. On the Set up network page, choose Off.

На странице управления учетными записями выберите Регистрация в Active Directory, а затем введите данные учетной записи. On the Account Management page, choose Enroll into Active Directory and then enter the account details.

На странице Добавить приложения, при необходимости, добавьте приложения. On the Add applications page, add applications if desired. Этот шаг является необязательным. This step is optional.

На странице Добавить сертификаты, при необходимости, добавьте сертификаты. On the Add certificates page, add certificates if desired. Этот шаг является необязательным. This step is optional.

На странице «Готово» нажмите кнопку Создать. On the Finish page, click Create.

В проводнике дважды щелкните файл виртуального жесткого диска для подключения образа диска. In file explorer, double-click the VHD to mount the disk image. Определите букву диска для подключенного образа. Determine the drive letter of the mounted image.

Введите следующую команду в командной строке с повышенными привилегиями. Type the following at an elevated command prompt. Замените букву G буквой диска подключенного образа, а затем введите используемое имя проекта, если оно отличается от предложенного: Replace the letter G with the drive letter of the mounted image, and enter the project name you used if it is different than the one suggested:

В проводнике щелкните правой кнопкой мыши подключенный образ и нажмите кнопку Извлечь. Right-click the mounted image in file explorer and click Eject.

См. инструкции в Загрузка и создание виртуальной машины из подготовленного виртуального жесткого диска для входа в Azure, получите сведения о вашей учетной записи хранения, загрузите виртуальный жесткий диск и создайте управляемый образ. See instructions at Upload and create VM from generalized VHD to log in to Azure, get your storage account details, upload the VHD, and create a managed image.

Виртуальные машины, подсоединенные к Azure Active Directory Azure Active Directory-joined VMs

В пакетах подготовки Azure Active Directory (Azure AD) превышено использование массовых маркеров в 180 дней. Azure Active Directory (Azure AD) provisioning packages have a 180 day limit on bulk token usage. Вам потребуется обновить пакет подготовки и повторно внедрить его в образ после 180 дней. You will need to update the provisioning package and re-inject it into the image after 180 days. Существующие присоединенные к Azure AD и развернутые виртуальные машины не потребуется создавать заново. Existing virtual machines that are Azure AD-joined and deployed will not need to be recreated.

Для виртуальных машин, присоединенных к Azure AD, выполните те же инструкции (выше), что и для виртуальных машин, присоединенных к Active Directory, со следующими исключениями: For Azure AD-joined VMs, follow the same instructions (above) as for Active Directory-joined VMs with the following exceptions:

В шаге 9, во время установки с помощью конструктора конфигурации Windows, в разделе имя введите имя для проекта, которое будет указывать, что он не предназначен для виртуальных машин, присоединенных к Active Directory, таких как Desktop Bulk Enrollment Token Pro GVLK. In step 9, during setup with Windows Configuration Designer, under Name, type a name for the project that indicates it is not for Active Directory joined VMs, such as Desktop Bulk Enrollment Token Pro GVLK.
На этапе 11 во время установки с помощью конструктора конфигураций Windows на странице Управление учетными записями вместо регистрации в Active Directory выберите пункт Регистрация в Azure AD, щелкните получить массовый маркер, войдите в систему и добавьте массовый маркер, используя учетные данные своей организации. In step 11, during setup with Windows Configuration Designer, on the Account Management page, instead of enrolling in Active Directory, choose Enroll in Azure AD, click Get Bulk Token, sign in and add the bulk token using your organization’s credentials.
На шаге 15 подраздела 2 при вводе PackagePath используйте название проекта, введенное на шаге 9 (например, » настольная система массовой регистрации» Pro GVLK. ppkg). In step 15, sub-step 2, when entering the PackagePath, use the project name you entered in step 9 (ex: Desktop Bulk Enrollment Token Pro GVLK.ppkg)
При попытке доступа к виртуальной машине с помощью удаленного рабочего стола, необходимо создать файл параметров RDP, как описано в разделе Создание настраиваемых параметров протокола удаленного рабочего стола для Azure. When attempting to access the VM using remote desktop, you will need to create a custom RDP settings file as described below in Create custom RDP settings for Azure.

Виртуальные машины Azure Gallery Azure Gallery VMs

Если вы должны активировать Windows 10 Pro, как описано в сценарии 3, выполните указанные ниже действия. If you must activate Windows 10 Pro as described for scenario 3, complete the following steps. В противном случае перейдите к действию 8. Otherwise, skip to step 8.

В разделе имя введите Desktop Bulk Enrollment Token Pro GVLK, нажмите кнопку Готовои затем на странице Настройка устройства введите имя устройства. Under Name, type Desktop Bulk Enrollment Token Pro GVLK, click Finish, and then on the Set up device page enter a device name.
В разделе Введите ключ продукта введите ключ Pro GVLK: W269N-WFGWX-YVC9B-4J6C9-T83GX. Under Enter product key type the Pro GVLK key: W269N-WFGWX-YVC9B-4J6C9-T83GX.

В поле имявведите массовую регистрацию для настольных систем, нажмите кнопку Готово, а затем на странице Настройка устройства введите имя устройства. Under Name, type Desktop Bulk Enrollment, click Finish, and then on the Set up device page enter a device name.

На странице Настройка сети выберите отключение. On the Set up network page, choose Off.

На странице «Управление учетными записями» выберите Регистрация в Azure AD, нажмите кнопку Получение массового маркера, войдите и добавьте массовый маркер с использованием учетных данных вашей организации. On the Account Management page, choose Enroll in Azure AD, click Get Bulk Token, sign in, and add the bulk token using your organizations credentials.

На странице «Добавить приложения», при необходимости, добавьте приложения. On the Add applications page, add applications if desired. Этот шаг является необязательным. This step is optional.

На странице «Готово» нажмите кнопку Создать. On the Finish page, click Create.

Скопируйте файл .ppkg на удаленную виртуальную машину. Copy the .ppkg file to the remote Virtual machine. Дважды щелкните его, чтобы запустить установку пакет подготовки. Double click to initiate the provisioning package install. Система перезагрузится. This will reboot the system.

При попытке доступа к виртуальной машине с помощью удаленного рабочего стола, необходимо создать файл параметров RDP, как описано ниже. When attempting to access the VM using remote desktop, you will need to create a custom RDP settings file as described below.

Создание настраиваемых параметров протокола удаленного рабочего стола для Azure Create custom RDP settings for Azure

Чтобы создать настраиваемые параметры протокола удаленного рабочего стола для Azure, сделайте следующее. To create custom RDP settings for Azure:

Откройте подключение к удаленному рабочему столу и введите IP-адрес или DNS-имя удаленного узла. Open Remote Desktop Connection and enter the IP address or DNS name for the remote host.

Нажмите кнопку Показать параметры, а затем под параметрами подключения нажмите кнопку Сохранить как и сохраните RDP-файл в расположение, где он будет использоваться. Click Show Options, and then under Connection settings click Save As and save the RDP file to the location where you will use it.

Закройте окно подключения к удаленному рабочему столу и откройте Блокнот. Close the Remote Desktop Connection window and open Notepad.

Перетащите RDP-файл в окно программы Блокнот для его редактирования. Drag the RDP file into the Notepad window to edit it.

Введите или замените строку, которая указывает уровень проверки подлинности с помощью следующих двух строк текста: Enter or replace the line that specifies authentication level with the following two lines of text:

enablecredsspsupport и уровень проверки подлинности появятся только один раз в файле. enablecredsspsupport and authentication level should each appear only once in the file.

Сохраните изменения, а затем используйте этот пользовательский RDP-файл с учетными данными Azure AD для подключения к виртуальной машине Azure. Save your changes, and then use this custom RDP file with your Azure AD credentials to connect to the Azure VM.