На этом компьютере не включены динамические миграции

Обновлено: 15.01.2025

Организация приобретает новое хранилище (например, SAN) или переходит на новое устройство SMB 3.0, поэтому требуется перенос виртуальных машин в рамках плановых работ по миграции.
Используемое хранилище больше не имеет свободного пространства либо не соответствует требованиям по числу операций ввода-вывода в секунду (IOPS), поэтому в срочном порядке требуется перенос виртуальных машин. Как показывает опыт, это наиболее распространенный сценарий.

Как работает динамическая миграция хранилища

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

В ходе динамической миграции создается копия VHD. Цикл переноса выглядит следующим образом:

Динамическая миграция хранилища инициируется из графического интерфейса или с помощью средств PowerShell.
В целевое расположение копируются VHD, файл Smart Paging, моментальные снимки и файлы конфигурации.
После запуска процесса копирования все записи, выполняемые на исходном VHD, зеркально отображаются на целевом VHD.
Когда копия VHD создана, виртуальная машина переходит на использование VHD в целевом расположении. Копия в целевом расположении актуальна, поскольку в ходе ее создания все текущие записи зеркально отображались.
Из исходного расположения удаляются VHD и файлы конфигурации.

Почитал я это дело и решил опробовать. Беру виртуалку с srv32 и хочу мигрировать на srv34. Щелкаем правой кнопкой мыши по виртуалке-Переместить.

Конечный компьютер не настроен для отправки или получения динамических миграций виртуальных машин. Что такое и как настроить динамическую миграцию в Windows Server 2012R2-01

Откроется мастер, жмем Далее.

Переместить виртуальную машину

Компьютер назначения не настроен для отправки или получения динамических миграций виртуальных машин. Чтобы устранить эту проблему измените параметры Hyper-V на конечном компьютере.

Кстати вы еще при данной операции перемещения виртуальной машины, можете спокойно поймать ошибку 0x8009030E, как ее решать читайте по ссылке слева

Идем на srv34, то есть на комп куда мы мигрируем. Выбираем Параметры Hyper-V

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

После чего у вас все поедет как нужно и вы больше не увидите данную ошибку.

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

Требования к настройке динамической миграции

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

Учетная запись пользователя с разрешением на выполнение различных действий. Членство в локальной группе администраторов Hyper-V или группе Администраторы на исходном и конечном компьютерах соответствует этому требованию, если не настроено ограниченное делегирование. Для настройки ограниченного делегирования требуется членство в группе "Администраторы домена".

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

Исходный и конечный компьютеры, которые принадлежат к одному домену Active Directory или принадлежат к доменам, которые доверяют друг другу.

средства управления Hyper-V, установленные на компьютере под управлением Windows Server 2016 или Windows 10, если эти средства не установлены на исходном или целевом сервере и вы запускаете средства с сервера.

Рассмотрите варианты проверки подлинности и сети

Рассмотрим, как вы хотите настроить следующие настройки:

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

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

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

"Сбой операции миграции виртуальной машины в источнике миграции. Не удалось установить соединение с именем главного компьютера: нет доступных учетных данных в пакете безопасности 0x8009030E.

Производительность: имеет ли смысл настроить параметры производительности? Эти параметры могут сократить нагрузку на сеть и ЦП, а также ускорить выполнение динамической миграции. Рассмотрите требования и инфраструктуру и протестируйте различные конфигурации, которые помогут вам принять решение. Параметры описаны в конце шага 2.

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

Шаг 1. Настройка ограниченного делегирования (необязательно)

Если вы решили использовать Kerberos для проверки подлинности динамического переноса трафика, Настройте ограниченное делегирование, используя учетную запись, которая является членом группы "Администраторы домена".

Использование оснастки "пользователи и компьютеры" для настройки ограниченного делегирования

Откройте оснастку "Active Directory - пользователи и компьютеры". (Из диспетчер сервера выберите сервер, если он не выбран, щелкните Сервис. Active Directory пользователей и компьютеров).

В области навигации в Active Directory пользователи и компьютерывыберите домен и дважды щелкните папку Компьютеры .

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

В окне Свойстваперейдите на вкладку Делегирование .

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

В меню Добавление службвыберите пункт Пользователи или компьютеры.

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

В окне Добавление службв списке доступных служб выполните следующие действия и нажмите кнопку ОК.

Для перемещения хранилищ виртуальной машины выберите cifs. Это необходимо, если требуется переместить хранилище вместе с виртуальной машиной, а также, если требуется переместить только хранилище виртуальной машины. Если сервер настроен для использования хранилища SMB для Hyper-V, этот параметр уже должен быть выбран.

Для перемещения виртуальных машин выберите Службу миграции виртуальной системы Майкрософт.

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

Изменения конфигурации вступят в силу после выполнения обоих следующих действий.

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

Шаг 2. Настройка исходного и конечного компьютеров для динамической миграции

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

Использование диспетчера Hyper-V для настройки исходного и конечного компьютеров для динамической миграции

Откройте диспетчер Hyper-V. (В диспетчер сервера щелкните инструменты . Диспетчер Hyper-V.)

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

в области действий щелкните Hyper-V Параметры динамической миграции.

На панели Динамические миграции проверьте, включен ли параметр Разрешить входящие и исходящие динамические миграции.

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

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

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

Выберите другой сервер в диспетчере Hyper-V и повторите эти действия.

использование Windows PowerShell для настройки исходного и конечного компьютеров для динамической миграции

Для настройки динамической миграции на некластеризованные узлы доступны три командлета: Enable-вммигратион, Set-вммигратионнетворки Set-vmhost. В этом примере используются все три и выполняется следующее:

Настройка динамической миграции на локальном узле
Разрешает входящий трафик миграции только в определенной сети
Выбирает Kerberos в качестве протокола проверки подлинности

Каждая строка представляет собой отдельную команду.

Set-VMHost также позволяет выбрать параметр производительности (и многие другие параметры узла). Например, чтобы выбрать SMB, но оставить для протокола проверки подлинности значение по умолчанию CredSSP, введите:

В этой таблице описано, как работают параметры производительности.

— SMB Direct используется, когда сетевые адаптеры на исходном и целевом серверах имеют включенные возможности удаленного доступа к памяти (RDMA).
— Многоканальный SMB автоматически обнаруживает и использует несколько подключений, если определена правильная конфигурация многоканального SMB.

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

И чтобы проще было другим отыскать корень проблемы пишу эту статью.

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

× Не удалось установить соединение с узлом: Предоставленные пакету учетные данные не были распознаны (0x8009030D)

× Не удалось установить соединение с узлом : В пакете безопасности отсутствуют учетные данные (0x8009030E)

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

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

Проделываем аналогичные настройки на других хостах (в моём случае необходимо выбрать хост V-TWO и делегировать доверие от служб V-ONE). Далее идём в настройки Hyper-V каждого хоста. Для этого открываем оснастку Hyper-V, выбираем нужный хост, правой кнопкой мышки, выбираем Параметры Hyper-V, далее Динамическая миграция, ставим галочку если не стоит Включить входящие и исходящие миграции, выбираем Использовать Kerberos, жмём Ok.

Чтобы настройки вступили в силу необходимо перезагрузить хост (гипервизор).

Если подключаться к диспетчерам hyper-v со сторонней машинки windows 8.1 Pro то проблема остаётся. Приходится по RDP к самим серверам подключаться.

у меня всё отлично работает и на 7 и на 8 и на 8.1

а если добавить стороннюю машину в список делегирования?

> Чтобы настройки вступили в силу необходимо перезагрузить хост (гипервизор).
Не нужно ничего перегружать. По крайней мере на WinServer 2012 R2 я сразу провёл миграцию, как только настроил делегирование Kerberos.

Живая миграция (live migration) – популярная функция в Hyper-V. Она позволяет переносить работающие виртуальные машины без видимого простоя. В сети много инструкций по переносу ВМ, но многие из них устарели. Вдобавок не все заглядывают в расширенные настройки и правильно используют возможности Live Migration.

Я собрал нюансы и неочевидные параметры для быстрого переноса ВМ внутри кластера и между кластерами. Заодно поделюсь маленькими секретами в настройке и проектировании. Надеюсь, статья будет полезна начинающим админам.

Дисклеймер: Все описанные шаги желательно сделать ДО ввода сервера Hyper-V в прод. Hyper-V никогда не прощает ошибок проектирования и подведет вас при первом удобном случае. То есть уже на следующий день.

Вспоминаем матчасть

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

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

По такой схеме работает классическая живая миграция внутри Failover Cluster. Для нее нужен общий том CSV, поданный всем хостам кластера.

Помимо этого есть второй вид Live Migration, живая миграция в режиме «ничего общего» (Shared-Nothing Live Migration). Этот сценарий обычно используется для миграции ВМ без простоя между кластерами. Помимо страниц памяти с одного хоста Hyper-V на другой копируется диск VHD(X) с переносом и синхронизацией дельты данных, записанных на него.

Разберем основные нюансы по настройке интерфейсов.

Задаем настройки протоколов

Возможность использовать этот протокол появилась в Windows Server 2016. SMB по умолчанию отдает трафик в несколько портов (SMB Multi-channel). Также он прекрасно работает с RDMA – адаптером удаленного прямого доступа к памяти. Это полезно для ускорения переноса кластеров.

Начиная с Windows Server 2016, службы работают в контексте NETWORK SERVICE, который не может имперсонироваться в AD. Так что в этом случае выбираем неограниченное делегирование (Unconstrained Delegation), но учитываем, что это довольно небезопасно:

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

Эти же настройки в более модном Windows Admin Center:

Разбираемся с конфигурацией сети

Сетевая оптимизация Hyper-V – это крайне дискуссионная тема в сообществе и безграничное поле для экспериментов (предела совершенству в нем нет по определению). Так что перед пошаговой настройкой сети разберемся, как технологии изменились за последнее время и как можно это использовать.

Как было раньше. Старые мануалы по переносу ВМ Hyper-V описывают сценарии с использованием технологии тиминга Load Balancing/Fail Over (LBFO). LBFO позволяла группировать физические сетевые адаптеры и создавать поверх них интерфейсы. Но были и минусы, например: не было поддержки RDMA, нельзя было выяснить, через какой порт тима будет идти трафик. А поскольку трафик живой миграции требует довольно жирного канала, это превращалось в проблему, когда все сетевые ворклоады ломились в один физический порт.

Как сейчас. В Windows Server 2019 даже нельзя создать виртуальный свитч поверх LBFO Team. Единственным поддерживаемым решением для объединения портов сетевой карты в Hyper-V остался Switch Embedded Team (SET).

SET агрегирует адаптеры, как и vSwitch у ESXi. Физические сетевые порты становятся патч-кордом для разных типов трафика (в том числе для ВМ), а поверх них нарезаются виртуальные интерфейсы.

Тут нужно добавить, что в типах гипервизоров есть небольшой рассинхрон. Англоязычные авторы считают, что есть только 2 типа, но на самом деле их 3 (подробно мы с коллегами описывали их в этом посте). Когда-то гипервизоры ESX были гибридного типа (1+). Это был такой модернизированный Red Hat c ролью гипервизора. VMware ушла от этого в vSphere 4.1 и стала честным гипервизором типа 1 (bare-metal).

Microsoft взяла опыт VMware на вооружение и реализовала Switch Embedded Team в Windows Server 2016. Эта схема показывает большую производительность и гибкость в управлении трафиком в рамках тиминга.

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

Как это влияет на процесс настройки. В Hyper-V, помимо менеджмент-интерфейса, мы обычно создаем интерфейсы для живой миграции и интерфейсы для CSV-трафика кластера. Для этого нам нужно знать количество сетевых портов, входящих в SET, – именно столько виртуальных интерфейсов нужно будет создать. Также учитываем расположение сетевых портов на PCI-шине, количество сокетов для последующего маппинга интерфейсов по NUMA-нодам и количество физических ядер на каждом процессоре.

Посмотрим на процесс пошагово

Имя сети	Назначение	Сеть	Шлюз	VLAN ID	Количество виртуальных адаптеров
Management	Управляющий интерфейс	192.168.1.0/24	192.168.1.1	0 (Native)	1
LiveMigration	Живая миграция	192.168.2.0/24	2	2
CSV	CSV-трафик	192.168.3.0/24	3	2

В результате мы создадим свитч с менеджмент-интерфейсом. MinimumBandwidthMode обязательно сразу задаем как weight, иначе после создания SET мы не сможем изменить этот параметр. Так пропускная способность сети будет указана в относительных числах. Это понадобится для настройки Network QoS Policies (а иначе они не будут работать).

После этого мы создаем сетевые интерфейсы по количеству физических портов на сетевой карте и «прибиваем» CSV-трафик и трафик живой миграции к каждому порту:

Тут без помощи сетевых инженеров не обойтись: потребуется настройка портов на сетевом оборудовании.

Синхронизируем метрики интерфейсов и снизим приоритет интерфейсов CSV-трафика. В моем случае задавал так:

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

До Windows Server 2019 настройка VMQ была обязательна, пока не появился dVMMQ. Он автоматически балансирует трафик и перекидывает его с ядра на ядро, как только нагрузка доходит 90%. Так что на Windows Server 2019 сидеть и высчитывать ядра для VMQ не нужно.

Посмотрим наглядно, как это работает. Предположим, у нас есть 2 процессора с 16 физическими ядрами. Это 32 логических ядра с учетом многопоточности. Открываем Excel и выписываем по порядку ядра от 0 до 31:

Для первого порта сетевого адаптера назначаем Base Processor Number 2. Для количества ядер берем степень двойки. В четвертой степени получим 16 – это значение задаем для MaxProcessorNumber.

BaseProcessor для второго адаптера тоже будет равен 16 (опять берем степень двойки). На картинке хорошо виден перехлест для обработки трафика на шестнадцатом ядре. Ситуация не критичная, так как нулевое ядро мы разгрузили и не используем для обработки Live Migration.

Настраиваем миграцию для кластеризованного сценария

Со стороны Failover Cluster дополнительно выкрутим настройки таймаутов кластера:

Чтобы трафик живой миграции использовался только на определенной сети, также оставим отдельную сеть в настройках Failover Cluster:

Собственно, это и есть минимальный джентльменский набор настроек для корректной работы Live Migration в Hyper-V.

30.03.2017

Hyper-V, Windows Server 2016

комментариев 14

Технология Live Migration в системе виртуализации Hyper-V позволяет перемещать запущенную виртуальную машину между хостами Hyper-V без прерывания ее работы и доступности сервисов. В ранних версиях Hyper-V виртуальную машину возможно было переместить с помощью Live Migration только между узлами кластера (Failover Cluster). В Hyper-V 3.0 (Windows Server 2012) и выше этого ограничения больше нет благодаря технологии Shared Nothing Live Migration. В этой статье мы покажем, как включить Live Migration и перенести запущенную ВМ между отдельно стоящими серверами Hyper-V на базе Windows Server 2016.

Требования, необходимые для выполнения Shared Nothing Live Migration:

Перемещение возможно между серверами со следующими версиями ОС: Windows Server 2012 R2 или Windows Server 2016
Версия виртуальной машины должна быть не ниже 5
Оба компьютера должны состоять в одном домене Active Directory, либо в доменах с двустороннем доверием
У пользователя выполняющего настройки должны быть права администратора Hyper-V. При настройке ограниченного делегирования Kerberos пользователь должен обладать правами администратора домена (либо ему должны быть предоставлены права на учетные записи серверов в AD)

Допустим у нас имеется 2 сервера с Windows Server 2016 с установленной ролью HyperV: Srv01 и Srv03. Оба сервера включены в домен Active Directory и не объединены в кластер WSFC (Windows Server Failover Clustering). Запустим на любом из серверов консоль Hyper-V Manager и добавим в нее оба сервера.

Затем в разделе настроек Advanced Features выберите протокол аутентификации Kerberos (Use Kerberos).

Рассмотренные выше действия можно выполнить с помощью таких команд PowerShell:

Enable-VMMigration
Set-VMMigrationNetwork 192.168.10.41 192.168.10.21

Set-VMHost -VirtualMachineMigrationAuthenticationType Примечание. Возможна живая миграция ВМ и с помощью протокола CredSSP, но в этом случае администратору потребуется выполнить локальный вход (по RDP) на сервер-источник миграции или подключиться удаленно через PowerShell Remoting.

Запустите оснастку ADUC , найдите учетную запись первого сервера Hyper-V, откройте его свойства и перейдите на вкладку Delegation (Делегирование).

Выберите опции: Trust this computer for delegation to specified services only и Use Kerberos only и нажмите на кнопку Add.

В следующем окне нажмите на кнопку Users and Computers и укажите имя второго сервера Hyper V. В списке доступных служб выберите Microsoft Virtual System Migration Service.

Совет. Если нужно также выполнять миграцию хранилища ВМ, нужно также выбрать протокол cifs

Сохраните настройки делегации. Аналогичные настройки проведите с учетной записью второго сервера Hyper-V.

Осталось дождаться репликации изменений в AD, и перевыпуска билета Kerboros и можно попытаться выполнить живую миграцию ВМ. Щелкните ПКМ по виртуальной машине и выберите Move. В качестве типа миграции выберите Move the virtual machine.

Укажите имя хоста Hyper-V, на который нужно выполнить перенос.

Затем укажите каталог на целевом хосте, в который нужно поместить файлы ВМ (каталог должен существовать).

Совет. Миграцию ВМ можно запустить с помощью такой PowerShell команды:

Move-VM srvapp1 Srv01 -IncludeStorage -DestinationStoragePath c:\hyperv\vm

В том случае, если в настройках ВМ не включен режим совместимости процессоров, миграция прервется с ошибкой:

The virtual machine cannot be moved to the destination computer. The hardware on the destination computer is not compatible with the hardware requirements of this virtual machine.

Для решения проблемы придется выключить ВМ и включить для нее режим совместимости CPU:

Читайте также: