Перемещение виртуальной машины hyper v на другой сервер

Перемещение виртуальной машины hyper v на другой сервер

Добрый день уважаемые читатели блога, я продолжаю знакомить вас с виртуализацией на базе Microsoft Hyper-V 3.0 и сегодня мы рассмотрим, как переместить виртуальную машину, с одного хоста на другой, в идеале без простоев и без наличия централизованных утилит управления, по типу SCVMM 2012 R2 и без общего хранилища. Думаю для начинающих системных администраторов, это будет полезно.

live migration в Hyper-V

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

Что переносится при live migration

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

Требования live migration

Давайте определимся, что необходимо для успешного перемещения виртуальной машины на Hyper-V 3.0:

И так на первом хосте, у меня есть виртуальная машина с именем dc7, ее я хочу переместить на другой хост Hyper-V. Для этого щелкаем по ней правым кликом и выбираем переместить.

первое окно мастера можно сразу пропускать, оно не несет ни какой полезности.

Далее у вас два варианта перемещения:

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

Далее задаем папку сохранения.

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

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

В диспетчере задач, можно про мониторить загрузку сети при перемещении.

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

Источник

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

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016

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

Для этого потребуются следующие возможности:

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

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

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

Перемещение работающей виртуальной машины с помощью диспетчера Hyper-V

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

В области виртуальные машины щелкните правой кнопкой мыши виртуальную машину и выберите пункт переместить. Откроется мастер перемещения.

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

На странице сводных данных просмотрите выбранные вами параметры и нажмите кнопку Готово.

перемещение работающей виртуальной машины с помощью Windows PowerShell

В следующем примере командлет Move-VM используется для перемещения виртуальной машины с именем лмтест на целевой сервер с именем TestServer02 и перемещения виртуальных жестких дисков и другого файла, таких как контрольные точки и файлы Smart paging, в каталог д:\лмтест на целевом сервере.

Устранение неполадок

Не удалось установить соединение

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

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

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

Не удалось выполнить, так как оборудование узла несовместимо

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

Виртуальную машину невозможно переместить на конечный компьютер. Оборудование конечного компьютера несовместимо с требованиями к оборудованию этой виртуальной машины.

Чтобы устранить эту проблему, завершите работу виртуальной машины и включите параметр совместимости процессора.

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

В области навигации разверните узел процессоры и выберите пункт Совместимость.

Установите флажок выполнить миграцию на компьютер с другой версией процессора.

Нажмите кнопку ОК.

чтобы использовать Windows PowerShell, используйте командлет Set-вмпроцессор :

Источник

Экспорт и импорт виртуальных машин

применимо к: Windows Server 2022, Windows 10, Windows Server 2016, Microsoft Hyper-V Server 2016, Windows server 2019, Microsoft Hyper-V server 2019

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

Экспорт виртуальной машины

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

Использование диспетчера Hyper-V

Чтобы экспортировать виртуальную машину:

В диспетчере Hyper-V щелкните правой кнопкой мыши виртуальную машину и выберите пункт Экспорт.

Выберите место хранения экспортируемых файлов и нажмите кнопку Экспорт.

После завершения экспорта можно просмотреть все экспортированные файлы в расположении экспорта.

Использование PowerShell

Откройте сеанс от имени администратора и выполните команду, как показано ниже, после замены и пути виртуальной машины <> :

Дополнительные сведения см. в разделе Export-VM.

Импорт виртуальной машины

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

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

Импорт с помощью диспетчера Hyper-V

Чтобы импортировать виртуальную машину, выполните следующие действия.

В меню действия в диспетчере Hyper-V щелкните Импорт виртуальной машины.

Щелкните Далее.

Выберите папку, содержащую экспортированные файлы, и нажмите кнопку Далее.

Выберите виртуальную машину для импорта.

Выберите тип импорта и нажмите кнопку Далее. (Описание см. в разделе типы импортаниже.)

Нажмите кнопку Готово.

Импорт с помощью PowerShell

Регистрация на месте

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

Восстановить

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

Импортировать как копию

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

Дополнительные сведения см. в статье Импорт-виртуальная машина.

Типы импорта

Hyper-V предлагает три типа импорта:

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

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

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

Источник

Клонирование, импорт и экспорт виртуальных машин в Hyper-V

В Hyper-V в отличии от VMWare нет встроенной функции клонирования виртуальной машины (клонирование есть только в Virtual Machine Manager). Чтобы создать полную копию существующей ВМ придется использовать функцию импорта/экспорта. В этой статье мы рассмотрим, как клонировать виртуальную машину в Hyper-V через импорт/экспорт через графический интерфейс Hyper-V Manager, PowerShell и Windows Admin Center (WAC).

%WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe

ВМ будет выключена и при следующей загрузке как оригинальной ВМ, так и ее клона для Windows будет сгенерирован новый SID. Также нежелательно клонировать ВМ, включенные в домен Active Directory.

Экспорт/импорт ВМ из консоли Hyper-V Manager

Сначала нужно экспортировать ВМ в отдельный каталог.

Запустите консоль Hyper-V manager, выберите ВМ и в контекстном меню выберите Export.

Укажите каталог, в который нужно экспортировать виртуальную машину.

Статус экспорта ВМ будет отображен в строке состояния ВМ в консоли Hyper-V.

Чтобы импортировать ВМ щелкните в консоли Hyper-V Manager по имени хоста и выберите Import Virtual Machine.

Затем нужно указать путь к каталогу, в котором находятся папки с файлами импортируемой ВМ. При импорте ВМ в Hyper-V предлагается 3 варианта регистрации ВМ на хосте:

Если вы попробуете импортировать ВМ с дублирующим ID, появится ошибка:

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

Затем укажите каталог для хранения виртуальных дисков vhdx ВМ.

После этого новая клонированная виртуальная машина появится в консоли Hyper-V.

Клонирование ВМ через экспорт/импорт в Hyper-V с помощью PowerShell

Рассмотрим, как клонировать виртуальную машину Hyper-V через импорт/экспорт из консоли PowerShell.

Для экспорта ВМ воспользуйтесь такой командой:

Если вы хотите экспортировать запущенную ВМ, вы можете использовать параметр CaptuteLiveState, в котором определяется как нужно копировать оперативную память ВМ. Доступны три опции

Если вы хотите экспортировать состояние ВМ в определеном снимке, нужно указать его имя.

Сначала выведите список снимков для указанной ВМ:

Затем выполните экспорт нужного снимка по его имени:

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

В параметре Path указываем расположение vmcx файла конфигурации ВМ (формат vmcx заменил XML формат конфигурационных файлов ВМ в Hyper-V Server 2016). Для копирования ВМ в другой каталог с тем же ID используйте параметр Copy. Чтобы сгенерировать нового идентификатор ВМ, используйте параметр GenerateNewId:

В параметре VhdDestinationPath указывается каталог, куда нужно скопировать VHDX файлы ВМ, а в параметре VirtualMachinePath — каталог конфигурационных файлов ВМ. Если эти параметры не задать, файлы ВМ будут скопированы в дефолтный каталог, указанный в настройках хоста Hyper-V (C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\).

Обратите внимание, что клонированная ВМ появилась в консоли Hyper-V с оригинальным именем. Переименуем новую ВМ, но сначала нужно получить ее ID:

get-vm | select VMNAME,VMId

Как вы видите в консоли есть две ВМ с одинаковым именем и разными ID. Нужно переименовать ВМ с ID, который отличается от ID импортируемой ВМ. Скопируйте ID новой ВМ и переименуйте ее:

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

Изменим MAC адрес виртуального адаптера (можно указать новый статический MAC или настроить динамическое получение MAC адреса).

Прежде, чем подключить новую ВМ в сеть, желательно переименовать ее и изменить IP адрес на новый (если используется DHCP адресация, этот шаг можно пропустить). В данном случае мы можем подключиться к новой ВМ через PowerShell Direct с помощью командлета Invoke-Command или Enter-PSSession:

Клонирование виртуальных машин Hyper-V через Windows Admin Center

Возможно клонировать ВМ Hyper-V напрямую без промежуточного экспорта/импорта появилась в Windows Admin Center v2009.

Затем нужно указать имя новой ВМ и каталог, в который нужно поместить ее файлы.

Обратите внимание, что мастере клонирования есть опция “I have already run sysprep on my VM”. Если вы не выполнили генерализацию образа с помощью Sysprep, и не включили эту опцию, Hyper-V создаст снапшот исходной ВМ, выполните ее Sysprep и склонирует в новую (исходная ВМ будет несколько раз перезагружена и не доступна для работы). После этого исходная ВМ будет возвращена в первоначальное состояние, а снапшот удален.

Дождитесь окончания клонирования ВМ. Новой ВМ автоматически будет присвоен новый ID.

А какие есть бесплатные способы сделать клон ВМ из ESXi в Hyper-V?

Из приличных был StarWind V2V Converter, вроде это функционал там бесплатные. можно еще тулзой disk2vhd

«зарегистрировать ВМ по хранения файлов» — что это?

Отсуствие грамотного редактора для вычитки 🙂
речь про «по месту хранения файлов»

Очень интересует последний способ, спасибо за него! Я поставил Windows Admin Center, она отлично встала на Windows Server 2022, я попробовал клонировать Windows 10 (заведено 2 юзера, оба админы).
Вот какую ошибку получаю:

Подробная информация об уведомлении
Ошибка
Не удалось клонировать виртуальную машину

00:43:25
Источник
Перейти в Виртуальные машины
Тип
Ошибка

Источник

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

Как настроить перенос работающих ВМ без простоя внутри кластера и между кластерами.

“Любишь Hyper-V – люби и PowerShell”

“А если любишь VMware ESXi, то люби PowerShell на пару с ESXi CLI и REST API”

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

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

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

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

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

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

Копирование страниц памяти с одного узла на другой и их синхронизация

Это и называется живой миграцией. Схема справедлива для любого гипервизора.

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

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

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

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

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

Authentication protocol: по умолчанию установлен протокол CredSSP – Credential Security Support Provider Protocol. Он прост в использовании, но, если в инфраструктуре несколько кластеров, мы не сможем перенести ВМ между кластерами.

Мы выберем Kerberos как более безопасный и подходящий для переноса ВМ между различными кластерами.

Performance options: здесь выбираем сетевой протокол. Живая миграция у нас будет работать поверх Switch Embedded Team по протоколу SMB (Server Message Block).

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

Kerberos позволяет переносить ВМ между кластерами, но требует настройки ограниченного делегирования (Kerberos Constrained Delegation) на объектах Computer в Active Directory.

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

Если живая миграция инициируется через System Center Virtual Machine Manager (SC VMM), то дополнительной настройки не нужно. SC VMM является доверенным сервисом для переноса машин по Shared-Nothing Live Migration.

Протокол SMB не требует особой настройки. Если мы находимся в доверенной среде, можно немного ускорить процесс Live Migration и отключить сквозное шифрование данных SMB:

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

Эти же настройки в более модном 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-нодам и количество физических ядер на каждом процессоре.

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

Создать SET через стандартный интерфейс можно с помощью Virtual Switch в VMM (Virtual Machine Manager). Если VMM нет, выполняем следующий скрипт PowerShell на каждом хосте Hyper-V:

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

Если мы настраиваем SET поверх RDMA-адаптеров, то MinimumBandwidthMode работать не будет ни в каком режиме. Следовательно, Network QoS Policies при включенном RDMA тоже работать не будут.

Алгоритм балансировки выставляем в Dynamic вместо дефолтного Hyper-V Port (в Windows Server 2019). Dynamic использует лучшие аспекты режимов Address Hash и Hyper-V Port и хорошо обрабатывает и входящий, и исходящий трафик:

Здесь нужно быть очень внимательным, особенно если мы создаем SET через SC VMМ и оставляем балансировку Host Default. В Windows Server 2016 алгоритмом по умолчанию был Dynamic. В Windows Server 2019 дефолтный алгоритм по непонятным причинам изменили на Hyper-V Port, так что можно и ошибиться.

Когда мы создали свитч, IP-адрес первого физического интерфейса мигрирует на виртуальный интерфейс свитча.

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

Теперь мы должны утилизировать все доступные нам оффлоады.

Например, я выкручиваю Jumbo Frames до 9K для всех типов трафика, кроме Management.

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

Названия свойств сильно зависят от модели сетевой карты, так как это не статические фичи Windows Server, а фичи конкретной модели сетевой карты. Чтобы использовать эти фичи, нужно ОБЯЗАТЕЛЬНО ставить драйверы от производителя сетевой карты и ни в коем случае не использовать стандартный драйвер Windows. Иначе сразу после создания SET может отвалиться сеть по Management’у. Список всех свойств сетевой карты можно получить через командлет Get-NetAdapterAdvancedProperties.

Проверим, что метрики сетевых интерфейсов равны:

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

Это нужно, чтобы трафик равномерно распределялся между физическими портами на равных.

Если карта поддерживает RDMA, то трафик живой миграции уместно перенести на нее. RDMA позволяет двум хостам обмениваться данными в их памяти без обращения к ОС хостов и без нагрузки на CPU. Поддержку RDMA на карте проверяем с помощью командлета Get-NetAdapterRdma.

Пример: что можно получить с помощью командлета. Скрин со statemigration.com

При этом сетевые ворклоады машин лучше оставить на встроенном или внешнем адаптере без RDMA (но, опять же, эта тема дискуссионная).

На сетевую производительность влияет расстояние до сокета процессора от конкретного порта и PCI-шины. Поэтому перейдем к маппингу виртуальных адаптеров и настройке Virtual Machine Queues (VMQ).

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

Настройка VMQ помогает учесть расположение на PCI-шине. По умолчанию, очереди обрабатываются нулевым ядром нулевого процессора. Это не очень хорошо: во-первых, мы его ОЧЕНЬ сильно греем, во-вторых, так мы просто не сможем выжать из сетевого порта больше 3 Гб. Это относится к трафику ВМ. Но у нас же другой трафик (SMB)! Значит, имеет смысл настроить RSS.

До 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.

Через эти же командлеты можно задать и количество RSS-очередей (RSS Queues). Их количество зависит от конкретной модели сетевой карты, поэтому перед настройкой RSS Queues нужно изучить документацию к сетевой карте.

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

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

SameSubnetDelay указывает, сколько раз в какое время мы посылаем хартбиты. По умолчанию он выставлен в 1 секунду.

Если узлы кластера находятся в одной сети, этого достаточно. Если они в разных сетях, то нужно настроить CrossSubnetDelay с теми же значениями.

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

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

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

Источник