Hyper-v или kvm? / хабр

Введение

История релиза Hyper-V Server 2019 получилась необычной и даже какой-то драматичной, как и все последние релизы от компании Microsoft. Поясню для тех, кто не в курсе. Сам 2019-й сервер зарелизился в октябре 2018 года с какими-то критичными багами. Подробности проблем не помню, но в итоге релиз отозвали. Через месяц зарелизили еще раз и вроде как успешно.

С сайта микрософт можно было скачать все версии 2019-го сервера, кроме бесплатной версии Hyper-V. Я следил за темой и все ждал, когда же появится iso образ с Hyper-V Server 2019, а его все не было и не было. Причем в Evaluation Center стояла пометка, что релиз пока откладывается, ждите, скоро все будет.

И вот дождались. 15-го июня я увидел новость о том, что Hyper-V Server 2019 доступен для загрузки в Evaluation Center. Зашел, проверил. В самом деле это так. Появился iso образ, который можно свободно загрузить, что я успешно сделал.

К слову, образ hyper-v 2019 гулял в сети, так как после первого релиза еще в октябре 2018, он был доступен и многие его скачали. Но там были какие-то баги. Из того, что я прочитал, люди указывали на то, что не работал rdp доступ к гипервизору. Не смог это проверить, так как у меня просто не проходила установка на сервер. Он то ли не устанавливался вовсе, выдавая ошибку в процессе установки, то ли потом в синий экран падал. Точно не помню. Я не стал разбираться, а поставил предыдущую версию. Как оказалось, не зря.

Повышение скорости динамической миграции

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

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

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

В диспетчере Hyper-V щелкните Действия > Параметры Hyper-V > Сервер > Динамическая миграция, а затем щелкните Дополнительные компоненты.
В разделе Параметры миграции > Параметры динамической миграции выполните одно из указанных ниже действий.
- Чтобы отключить ускоренную динамическую миграцию, щелкните Стандартная динамическая миграция.
- Чтобы использовать сжатие для ускорения динамической миграции, щелкните Использование сжатия.
- Чтобы использовать SMB для ускорения динамической миграции, щелкните Использование SMB как транспортного протокола.

Microsoft Hyper-V

В «магическом квадранте» Gartner по виртуализации серверной инфраструктуры х86 (Magic Quadrant for x86 Server Virtualization Infrastructure), выпущенном в июле 2015 года, лидируют Micrоsoft и VMware. Xen и KVM представлены вендорами Citrix и Red Hat.способны отлично работать под Hyper-VLinux Integration Services 4.0 for Hyper-Vпакет драйверов, утилит и улучшений для гостевых ОС LinuxОсобенности Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition

Максимальное число одновременно работающих ВМ	1024
Максимальное число процессоров на хост-сервер	320
Число ядер на процессор хоста	Не ограничено
Максимальное число виртуальных процессоров (vCPU) на хост-сервер	2048
Максимальная емкость оперативной памяти на хост-сервер	4 Тбайт
Память на одну ВМ	1 Тбайт
Виртуальных процессоров на ВМ	64 vCPU
Динамическое перераспределение памяти	Dynamic Memory
Дедупликация страниц памяти	Нет
Поддержка больших страниц памяти (Large Memory Pages)	Да
Централизованное управление	Да, System Center Virtual Machine Manager (SCVMM)
Интеграция с Active Directory	Да (через SCVMM)
Снимки ВМ (snapshot)	Да
Управление через браузер	Через портал самообслуживания
Обновления хост-серверов/ гипервизора	Да
Управление сторонними гипервизорами	Да, управление VMware vCenter и Citrix XenCenter
Обновление ВМ	Да (WSUS, SCCM, VMST)
Режим обслуживания (Maintenance Mode)	Да
Динамическое управление питанием	Да, Power Optimization
API для резервного копирования	Да, VSS API
Шаблоны виртуальных машин (VM Templates)	Да
Профили настройки хостов (Host Profiles)	Да
Миграция физических серверов в виртуальные машины (P2V)	Нет
Горячая миграция виртуальных машин	Да, без общего хранилища (Shared Nothing), поддержка сжатия и SMB3, неограниченное число одновременных миграций
Горячая миграция хранилищ ВМ	Да
Профили хранилищ	Да
Поддержка USB	Нет (за исключением Enhanced Session Mode)
Горячее добавление устройств	Только устройства хранения и/или память
Устройства Floppy в ВМ	1
Сетевые адаптеры/интерфейсы	8 NIC
Виртуальные диски IDE	4
Емкость виртуального диска	64 Тбайта для VHDX
Максимальное число узлов в кластере	64
Виртуальных машин в кластере	8000
Функции высокой доступности при сбоях хост-серверов	Failover Clustering
Перезапуск виртуальных машин в случае сбоя на уровне гостевой ОС	Да
Обеспечение доступности на уровне приложений	Да (Failover Clustering)
Непрерывная доступность ВМ	Нет
Репликация виртуальных машин	Да, Hyper-V Replica
Автоматическое управление ресурсами кластера	Да, Dynamic Optimization
Пулы ресурсов	Да (Host Groups)
Проверка совместимости процессоров при миграциях машин	Да, Processor Compatibility
Поддерживаемые хранилища	SMB3, FC, Virtual FC, SAS, SATA, iSCSI, FCoE, Shared VHDX
Кластерная файловая система	CSV (Cluster Shared Volumes)
Поддержка Boot from SAN	Да (iSCSI, FC)
Динамическое выделение емкости хранения (Thin Provisioning)	Да, Dynamic Disks
Загрузка с USB	Нет
Хранилища на базе локальных дисков серверов	Storage Spaces, Tiered Storage
Уровни обслуживания для подсистемы ввода-вывода	Да, Storage QoS
Поддержка NPIV	Да (Virtual Fibre Channel)
Поддержка доступа по нескольким путям (multipathing)	Да (DSM и SMB Multichannel)
Кэширование	Да, CSV Cache
API для интеграции с хранилищами	Да, SMI-S/SMP, ODX, Trim
Поддержка NIC Teaming	Да
Поддержка Private VLAN	Да
Поддержка Jumbo Frames	Да
Поддержка Network QoS	Да
Поддержка IPv6	Да
Мониторинг трафика	Да

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

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

В проекте «Миграция Azure» щелкните Серверы > Azure Migrate: Server Migration (Миграция Azure: миграция сервера) и выберите Репликация серверов.
В области Репликация компьютеров щелкните правой кнопкой мыши виртуальную машину и выберите Миграция.
В разделе Миграция > Shut down virtual machines and perform a planned migration with no data loss (Завершить работу виртуальных машин и выполнить запланированную миграцию без потери данных?) выберите вариант Да > ОК.
- По умолчанию Миграция Azure выключает локальную виртуальную машину и запускает репликацию по требованию для синхронизации любых изменений виртуальной машины, которые произошли с момента последней репликации. Это гарантирует отсутствие потери данных.
- Если вы не хотите выключать виртуальную машину, выберите вариант Нет.
Запустится задание миграции виртуальной машины. Отслеживайте задание в уведомлениях Azure.
После завершения работы вы можете просматривать виртуальную машину и управлять ею на странице Виртуальные машины.

Схема работы DRS в облаке MCS

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

Внутреннее название сервиса — Katana. Его бэкенд, написанный на Python, регулярно извлекает информацию о сущностях облака, используя OpenStack API. Под сущностями понимаются виртуальные машины, гипервизоры, диски и так далее. В выборку попадают только те характеристики, которые можно получить из OpenStack: количество элементов, их конфигурация и так далее. Утилизация ресурсов на этом этапе не извлекается.
Katana — Stateless-приложение, но для хранения своего кэша она использует memcached (MemCache). Отсюда данные впоследствии попадают в UI-утилиты для отображения операторам системы.

Фактически наша утилита представляет собой кэширующий слой для OpenStack. Все данные, которыми она оперирует, — это JSON, полученные из OpenStack и представленные в UI в табличном виде.
Для оптимальной работы алгоритма DRS данных из Openstack недостаточно. Поэтому сбор информации о фактическом использовании ресурсов с виртуальных машин производится с помощью специального сервиса katana-client раз в 10 секунд. Данные берутся из Libvirtd и носят инкрементный характер, так как для их получения используются нарастающие счетчики.
Данных, получаемых с katana-client, очень много, и они не преобразованы в значения per second. Поэтому собранные данные из katana-client передаются во вспомогательный HTTP + API сервис katana-collector.
Katana-collector выполняет расчет утилизации ресурсов в секунду на основе инкрементных данных, полученных из katana-client.
На основе полученных данных принимаются решения о балансировке различных кластеров гипервизоров.

Специальный алгоритм ищет гипервизоры, на которых утилизация процессора либо остаток свободной физической памяти выходят за рамки пороговых значений, указанных в настройках. Например, утилизация составляет 70% или количество физической памяти менее 64 GB. При обнаружении таких гипервизоров их ВМ перемещаются на гипервизоры с допустимым уровнем утилизации и свободной памяти — например, не более 50% и не менее 64 GB.

Для переноса выбираются, разумеется, не все ВМ с исходного гипервизора. Возможны следующие варианты:
- На исходном гипервизоре чрезмерное потребление памяти. В этом случае будет выполнена миграция большого количества маленьких виртуальных машин для быстрого освобождения памяти до допустимого значения, заданного конфигурацией.
- На исходном гипервизоре повышенная утилизация процессора. При таких условиях будет выполнена миграция наиболее сильно утилизирующих процессор виртуальных машин. Утилизация считается в отношении на 1 ядро, то есть в ситуации 4vCPU/400% (CPU Load) и 16vCPU/400% (CPU Load) будет выбрана виртуалка с 4 ядрами.
- На исходном гипервизоре повышенная утилизация и памяти, и процессора. В таком случае для миграции будут выбраны самые небольшие ВМ, наиболее интенсивно использующие процессор. Используемая в алгоритмах функция нормализации построит дерево, которое будет в каждом случае индивидуальным.
Все фигурирующие в расчетах цифры хранятся в конфигурационном файле и при необходимости могут быть изменены. В случае ручной миграции, которая доступна непосредственно из UI утилиты, пороговые значения настраиваются в интерфейсе.
Если алгоритм, лежащий в основе автоматической миграции, находит ВМ, которые следует переместить для более оптимального распределения ресурсов, выполняется миграция с использованием OpenStack API.

Примечание: описание процесса авторизации осталось за пределами изображенной ниже схемы, но фактически пользователь получает всю информацию напрямую из Memcached через Nginx, без использования каких-либо Python-библиотек и так далее. При этом авторизация в утилите организована так, как если бы пользователь работал непосредственно с OpenStack с использованием его токена.

Схема работы DRS в облаке MCS. Базовые компоненты

Миграция виртуальной машины между двумя изолированными узлами

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

В узле Виртуальные машины (VM) и службы > Все узлы выберите исходный изолированный узел, с которого нужно выполнить миграцию.
Щелкните узел, а затем в области Виртуальные машины выберите работающую виртуальную машину, которую нужно перенести. Запустите машину, если она не работает.
На вкладке Виртуальная машина щелкните Выполнить миграцию виртуальной машины, чтобы запустить мастер миграции виртуальной машины.
На странице Выбор узла проверьте узлы назначения и связанные с ними типы переноса. Тип переноса Динамический отображается, если для обоих узлов настроено подключение к одной и той же общей папке SMB 3.0.
Выберите узел назначения с типом переноса Динамический и нажмите кнопку Далее.
В разделе Сводка нажмите кнопку Переместить. Чтобы просмотреть состояние задания, откройте рабочую область Задания.
Чтобы проверить, была ли виртуальная машина перенесена, просмотрите список Виртуальные машины на узле назначения и убедитесь в том, что виртуальная машина работает.

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

Примечание

Эта функция применима к DPM 2019 UR2 и более поздних версий.

В этом разделе содержатся сведения о настройке сходства между виртуальными и физическими сетевыми адаптерами. Сходство между виртуальными и физическими сетевыми адаптерами обеспечивает гибкость маршрутизации сетевого трафика между объединенными физическими сетевыми адаптерами. С помощью этой функции можно увеличить пропускную способность, сопоставляя физический адаптер с поддержкой RDMA с виртуальным адаптером с поддержкой настроек RDMA. Кроме того, можно маршрутизировать конкретный тип трафика (например, динамическая миграция) на физический адаптер с более высокой пропускной способностью. В сценариях развертывания HCI настройка сходства позволяет использовать SMB Multichannel для обеспечения высокой пропускной способности трафика SMB.

Перед началом

Убедитесь, что:

Логический коммутатор развертывается на узле.
На логическом коммутаторе включено свойство объединения SET.

Выполните следующие действия:

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

Последовательно выберите Структура > Серверы > Все узлы > группа узлов > Узлы > Узел. Щелкните правой кнопкой мыши Узел, выберите пункт Свойства и перейдите на вкладку Виртуальные коммутаторы.
Убедитесь, что здесь добавлены физические адаптеры, которые требуется объединить. Сходство может быть сопоставлено только для физических адаптеров, добавленных здесь.
Щелкните Создать виртуальный сетевой адаптер, чтобы добавить новый виртуальный сетевой адаптер на виртуальный коммутатор.
По умолчанию для сходства установлено значение None. Этот параметр соответствует существующему поведению, при котором операционная система распространяет трафик с виртуального сетевого адаптера на любые объединенные физические сетевые адаптеры.
Установите сходство между виртуальным и физическим сетевым адаптером, выбрав физический адаптер в раскрывающемся меню.
После определения сходства трафик с виртуального сетевого адаптера направляется на сопоставленный ему физический адаптер.

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

Часто задаваемые вопросы

Вопрос. Я развернул коммутатор SET Enabled и выполнил объединение трех физических адаптеров pNIC1, pNIC2 и pNIC3. Я настроил сходство между виртуальным сетевым адаптером 1 и физическим сетевым адаптером 1. Если по каким-то причинам физический сетевой адаптер 1 выйдет из строя, прекратится ли передача трафика с виртуального сетевого адаптера 1?

Плюсы и минусы Hyper-V

Расскажу немного, почему я постоянно пользуюсь hyper-v наравне с другими гипервизорами (в основном KVM). В общем и целом мне нравится этот гипервизор, поэтому я и решил внимательно проработать вопрос установки и первоначальной настройки для дальнейшего использования по мере необходимости. К плюсам hyper-v в целом и бесплатной версии в частности я отношу следующие моменты:

Поддержка всех популярных ОС. Нет никаких проблем с совместимостью, нет необходимости отдельно ставить какие-то драйвера или тулсы. Поддержка hyper-v присутствует во всех windows системах, в ядре линукс, не помню точно с какой версии, но все современные системы ее имеют, в ядре freebsd, начиная с 10-й версии. То есть вы просто берете установочный диск и ставите систему на hyper-v, больше от вас ничего не требуется.

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

Обращаю на это особое внимание. По мне так это самый существенный плюс Hyper-v.

Стандартная панель управления гипервизором, которую можно установить на компьютер под управлением windows

К ней прибавился web доступ через windows admin center. Расскажу об этом далее подробнее.
В основе Hyper-V Server популярная серверная система, с которой понятно и удобно работать. К примеру, чтобы загрузить или забрать файл с гипервизора, вам достаточно расшарить на нем папку стандартным образом, как вы это делаете в любой windows системе.

Hyper-V можно установить на псевдорейды, такие как встроенный рейд контроллер от intel, или собрать софтовый рейд средствами самой ОС Windows.

Полнофункциональная бесплатная версия, правда без удобных средств управления.

Удобная работа со снепшотами из коробки. Не надо думать над форматами файлов, как в KVM. В Hyper-V он один и отлично поддерживает снепшоты.

Это мое личное мнение, основанное на опыте работы с малыми и средними компаниями, где нет каких-то особенных требований к надежности и доступности сервисов. Где используются несколько серверов с виртуальными машинами, не всегда есть домен windows. Конечно, помимо плюсов, есть и минусы. Первый и главный для меня минус — первоначальная настройка. Нельзя просто взять, установить Hyper-V Server и начать им пользоваться. Необходимо производить какие-то непонятные и не очевидные действия на хосте и управляемой машине. Дальше вы поймете, что я имею ввиду. Но преодолев это препятствие, можно спокойно использовать виртуальную инфраструктуру, основанную на бесплатном гипервизоре от microsoft.

Второй минус — нет никакой возможности пробросить USB в виртуальную машину. Подчас это очень неудобно и вынуждает использовать что-то другое, вместо Hyper-V. Не понимаю, почему в Microsoft за столько лет не могут это исправить. Запрос очень актуальный и злободневный, особенно у нас, где повсеместно используется 1С с USB ключами.

Step 2: Configure the source and destination computers for live migration

In this step, you will enable live migrations, configure the source and destination servers so they will send and receive live migrations, optionally configure the authentication protocol. When you configure the servers, you choose whether to allow live migration traffic on any available network, or only on specified networks. As a security best practice, we recommend that you select specific networks to use for live migration traffic, as discussed in the “Prerequisites” section.

To configure the source and destination computers for live migration

Open Hyper-V Manager if it is not already open. (From Server Manager, click Tools and then click Hyper-V Manager.)
In the navigation pane, select one of the servers that you want to configure for live migrations. (If none of the servers are listed, click Hyper-V Manager in the navigation pane. Then, in the Action pane, click Connect to Server and specify each server name. After that, select one of the servers in navigation pane.)
In the Action pane, click Hyper-V Settings.
In Hyper-V Settings dialog box, click Live Migrations.
In the Live Migrations pane, check Enable incoming and outgoing live migrations.
Under Simultaneous live migrations, specify a different number if you don’t want to use the default of 2.
Under Incoming live migrations, if you want to use specific network connections to accept live migration traffic, click Add to type the IP address information. Otherwise, click Use any available network for live migration. Click OK.
If you have configured constrained delegation in Step 1: Configure constrained delegation, expand Live Migrations and then select Advanced Features.

In the Advanced Features pane, under Authentication protocol, select Kerberos.
Click OK.
Select the other server in Hyper-V Manager and repeat the remaining steps.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

To use Windows PowerShell to configure a server running Hyper-V for live migration, you can use the Enable-VMMigration, Set-VMMigrationNetwork, and Set-VMHost cmdlets, depending on how you want to configure the host. The following example commands configure live migration on the local host, allow incoming migration traffic only on the specified network, and specify Kerberos as the authentication protocol. Each line represents a separate command.

Choose Kerberos authentication

By default, Hyper-V hosts use CredSSP to authenticate with member of the cluster to run Live Migration. Microsoft chooses CredSSP by default because there is no further configuration to apply in order that Live Migration works. However, CredSSP has two main issues regarding Kerberos:

CredSSP is less secure than Kerberos

CredSSP doesn’t allow to pass credential in more than one hop. So, if you want to run a Live Migration, you must login on the node which hosts the VM you want to migrate.

For this reason, I prefer to spend time on Kerberos configuration than staying in CredSSP authentication. In order to Kerberos works, you have to configure constrained delegation in Active Directory. For example, in my 2-Node S2D cluster, I have the following configuration in each AD computer object:

Each computer account can present delegated credentials to other nodes in the cluster for the service CIFS and Microsoft Virtual System Migration Service. For two nodes, you can do it manually but if you have 40 nodes or more, it will be endless. So I have written a script for that:

$Nodes = «node01″,»node02″,»node03″,»node04″,»etc….»

$DomainName = «mydomain.local»

Foreach ($Node in $Nodes){

Write-Host «——— $Node ——«

Foreach ($VMHost in $Nodes){

If ($Node -notlike $VMHost){

Write-Host » -> $VMHost»

Get-ADComputer $Node | Set-ADObject -Add @{«msDS-AllowedToDelegateTo»=»Microsoft Virtual System Migration Service/$($VMHost).$($DomainName)», «cifs/$($VMHost).$DomainName»,»Microsoft Virtual System Migration Service/$($VMHost)»,»cifs/$($VMHost)»}

}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$Nodes=»node01″,»node02″,»node03″,»node04″,»etc….»

$DomainName=»mydomain.local»

Foreach($Node in$Nodes){

Write-Host»——— $Node ——«

Foreach($VMHost in$Nodes){

If($Node-notlike$VMHost){

Write-Host» -> $VMHost»

Get-ADComputer$Node|Set-ADObject-Add@{«msDS-AllowedToDelegateTo»=»Microsoft Virtual System Migration Service/$($VMHost).$($DomainName)»,»cifs/$($VMHost).$DomainName»,»Microsoft Virtual System Migration Service/$($VMHost)»,»cifs/$($VMHost)»}

}

}

}

Thank to this script, the constrained delegation is set for each node in the cluster. Moreover, if you add another node in the cluster, you can run again this script without impact.

Then you can set Kerberos authentication in each node:

You can also do it by using a script:

$Nodes = Get-ClusterNode -cluster «MyClusterName» | Select -Expand Name

Enable-VMMigration –Computername $Nodes -ErrorAction Stop| Out-Null

Set-VMHost –Computername $Nodes `

–VirtualMachineMigrationAuthenticationType Kerberos

1
2
3
4
5
6
7

$Nodes=Get-ClusterNode-cluster»MyClusterName»|Select-Expand Name

Enable-VMMigration–Computername$Nodes-ErrorAction Stop|Out-Null

Set-VMHost–Computername$Nodes`

–VirtualMachineMigrationAuthenticationType Kerberos

Поддерживаемые версии настройки виртуальных машин

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

если необходимо создать виртуальную машину, которую можно переместить на узел Hyper-V, на котором работает более старая версия Windows, используйте командлет New-VM с параметром-version. например, чтобы создать виртуальную машину, которую можно переместить на узел Hyper-V, работающий Windows Server 2012 R2, выполните следующую команду. Эта команда создаст виртуальную машину с именем «WindowsCV5» и конфигурацией версии 5,0.

Примечание

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

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

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

Версия Windows для узла Hyper-V	9.1	9.0	8.3	8.2	8.1	8.0	7.1	7,0	6,2	5.0
Windows Server 2019
Windows 10 Корпоративная LTSC 2019
Windows Server 2016
Windows 10 Корпоративная 2016 с долгосрочным обслуживанием
Windows 10 Корпоративная 2015 с долгосрочным обслуживанием
Windows Server 2012 R2
Windows 8.1

Поддерживаемые версии конфигурации виртуальных машин для узлов каналов Semi-Annual

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

Версия Windows для узла Hyper-V	9.1	9.0	8.3	8.2	8.1	8.0	7.1	7,0	6,2	5.0
обновление Windows 10 за май 2019 г. (версия 1903)
Windows Server версии 1903
Windows Server, версия 1809
обновлении Windows 10 за октябрь 2018 г. (версия 1809);
Windows Server, версия 1803
Windows 10, обновление за апрель 2018 г. (версия 1803)
Windows 10 Fall Creators Update (версия 1709)
Обновление Windows 10 Creators Update (версия 1703)
Юбилейное обновление Windows 10 Anniversary Update (версия 1607)

Requirements for setting up live migration

To set up non-clustered hosts for live migration, you’ll need:

A user account with permission to perform the various steps. Membership in the local Hyper-V Administrators group or the Administrators group on both the source and destination computers meets this requirement, unless you’re configuring constrained delegation. Membership in the Domain Administrators group is required to configure constrained delegation.
The Hyper-V role in Windows Server 2016 or Windows Server 2012 R2 installed on the source and destination servers. You can do a live migration between hosts running Windows Server 2016 and Windows Server 2012 R2 if the virtual machine is at least version 5. For version upgrade instructions, see Upgrade virtual machine version in Hyper-V on Windows 10 or Windows Server 2016. For installation instructions, see Install the Hyper-V role on Windows Server.
Source and destination computers that either belong to the same Active Directory domain, or belong to domains that trust each other.
The Hyper-V management tools installed on a computer running Windows Server 2016 or Windows 10, unless the tools are installed on the source or destination server and you’ll run the tools from the server.

Подготовка выполняется впервые

Если это первая виртуальная машина, которую вы реплицируете в проекте службы «Миграция Azure», служба «Миграция Azure»: миграция сервера автоматически подготавливает эти ресурсы в той же группе ресурсов, что и проект.

Учетная запись хранения кэша. Программное обеспечение поставщика Azure Site Recovery, установленное в узлах Hyper-V, отправляет данные репликации для виртуальных машин, настроенных для репликации, в учетную запись хранения (которая называется учетной записью хранения кэша или учетной записью хранения журнала) в подписке. Затем служба «Миграция Azure» копирует отправленные данные репликации из учетной записи хранения на управляемые репликой диски, которые соответствуют виртуальной машине. Учетную запись хранения кэша нужно указать при настройке репликации для виртуальной машины. Портал Миграции Azure автоматически создает эту учетную запись для проекта Миграции Azure при первой настройке репликации в проекте.

Перед началом работы

Перед выделением подготовленного хранилища узлам и кластеру, хранилище необходимо обнаружить и классифицировать в структуре VMM.

Обнаружение и классификация хранилища
- Добавьте и классифицируйте устройства блочного хранилища. Сведения о классификации.
Выделите блочное хранилище для групп узлов. Можно выделить весь пул носителей или конкретные логические устройства (LUN).
Перед выделением хранилища для узлов необходимо выполнить указанные ниже действия.
- MPIO. Если вы используете хранилище Fibre Channel или iSCSI, на каждом узле необходимо включить функцию многопутевого ввода-вывода Multipath I/O (MPIO).
  - Если функция MPIO включена до добавления узла, VMM автоматически включит ее для поддерживаемых массивов хранения с помощью модуля DSM от корпорации Майкрософт. При наличии модулей DSM от конкретного поставщика будут использоваться они.
  - Если вы добавляете узел в VMM и включаете функцию MPIO позднее, ее необходимо настроить вручную, добавив обнаруженные идентификаторы оборудования для устройств.
- HBA и разделение на зоны. При использовании сети хранения данных (SAN) Fibre Channel на каждом узле должен быть установлен адаптер шины (HBA) и выполнено правильное разделение на зоны.
- iSCSI. Если используется сеть SAN iSCSI, убедитесь в том, что добавлены порталы iSCSI и инициатор iSCSI выполнил вход в массив. Убедитесь в том, что на каждом узле запущена служба инициатора iSCSI (Майкрософт) с параметром Автоматически.
- Группа хранения. Объясните администратору хранилища, как VMM управляет хранилищем.
  - В VMM группа хранения связывает инициаторы узлов, целевые порты и логические устройства.
  - Группа хранения содержит один или несколько идентификаторов инициаторов узлов (IQN или WWN) (WWN).
  - Группа хранения включает один или несколько целевых портов, а также одно или несколько логических устройств. Инициаторы устройств обращаются к логическим устройствам через целевые порты.
  - По умолчанию, когда диспетчер VMM управляет назначением логических единиц, он создает одну группу хранения на каждый автономный узел или узел кластера.
  - Для некоторых массивов хранения рекомендуется использовать одну группу хранения для всего кластера, когда инициаторы узлов для всех узлов кластера находятся в одной группе хранения. Для этого следует задать для свойства CreateStorageGroupsPerCluster значение $true, используя командлет Set-SCStorageArray.

Обходной путь

Чтобы решить эту проблему, используйте выход команды для определения объекта групповой политики (GPO), который изменяет параметры прав пользователей. Затем используйте один из следующих методов, чтобы устранить проблему:

Способ 1

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

Способ 2

На компьютере хост-Hyper-V следующие действия:

Во входе на компьютер в качестве администратора домена.
Установите функцию управления групповой политикой на консоли Server Manager.
После установки откройте оснастку MMC GPMC и просмотрите политику, которая управляет правами пользователей.
Изменить политику, чтобы включить виртуальные машины NT\Виртуальные машины в записи для входа в качестве службы.
Закрой редактор политики.
Запустите на Hyper-V для обновления политики. Возможно, потребуется подождать несколько минут, пока произойдет репликация Active Directory.

Способ 3

На клиентом компьютере с Windows 8, который поддерживает функцию клиент Hyper-V:

Во входе на компьютер в качестве администратора домена.
Установите клиент Hyper-V.
Установите Windows 8 удаленного администрирования сервера (RSAT).
Откройте консоль управления групповой политикой и просмотрите политику, управляющую правами пользователей.
Изменить политику, чтобы включить виртуальную машину NT\Virtual Machines в записи для входа в систему как права пользователя службы.
Закрой редактор политики на клиенте.
Запустите на Hyper-V, чтобы обновить политику. Возможно, потребуется подождать несколько минут, пока произойдет репликация Active Directory.

Видео

Пока я не осилил запись и монтаж видео по новой версии. Кому недостаточно текста и очень хочется посмотреть видео по установке и настройке Hyper-V, предлагаю ролик от прошлой версии. Там почти все то же самое. По крайней мере основное так точно.

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .