Запуск или динамическая миграция виртуальных машин hyper-v может завершиться ошибкой 0x80070569

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

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

Получим список ВМ Hyper V, что бы узнать какую машину экспортировать:

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

Где:

• Name — имя ВМ, которую экспортируем
• Path — путь, где будет лежать копия виртуальной машины Hyper V

Так как мы можем выполнить клонирование и включенной машины, то у нас есть несколько способов манипулировании с памятью. Для этого есть ключ CaptuteLiveState, которого нет в версии Windows Server 2012 r2 и ниже, со значениями:

• CaptureSavedState — включает оперативную память
• CaptureDataConsistentState — используется Production checkpoint
• CaptureCrashConsistentState — память не сохраняется

По умолчанию используется CaptureSavedState.

Для импорта есть три варианта сохранения идентификаторов, которые описывались выше.

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

VMCX — это файл, который лежит в папке «Virtual Machines» экспортированной ВМ. Если виртуальная машина с этим идентификатором уже есть в Hyper V вы получите ошибку:

Import-VM : Failed to create virtual machine. The operation failed because a virtual machine with the same identifier already exists. Select a new identifier and try the operation again.

Для импорта ВМ, с сохранением идентификаторов, но в новое место на диске выполните:

Где:

• VhdDestinationPath — куда будет скопирован виртуальный диск Hyper V
• VirtualMachinePath — куда будут скопированы файлы конфигурации виртуально машины
• Copy — указывает, что это операция копирования

Дополнительные ключи:

• SnapshotFilePath — куда будут скопированы чекпоинты
• SmartPagingFilePath — куда будет скопирован файл подкачки

Можно не указывать каждый тип файлов, а просто указать файл конфигурации в Path и действие Copy — тогда ВМ будет скопирована в местоположение указанное в настройках Hyper V.

В случае копирования VM с генерированием нового идентификатора можно сделать так:

В этом случае все файлы будут перемещены в папку, которая была указана в настройках Hyper V. Операция клонирования выполнена.

…

Рекомендую

Требуется ли физическая сетевая команда?

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

С помощью SET физические сетевые адаптеры на узле Hyper-V подключаются и объединяются виртуальным коммутатором. Это предполагает определенные предпосылки:

• Два сервера под управлением Windows Server 2016 Datacenter edition или Windows Server 2016 Standard edition
• Один сертифицированный сетевой адаптер с поддержкой RDMA, установленный на каждом сервере
• Роль сервера Hyper-V, установленная на каждом сервере

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

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

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

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

• SameSubnetThreshold показывает, сколько хартбитов мы можем максимально пропустить. По дефолту это 5 хартбитов, максимум – 120. Мы поставим оптимальное значение – 30 хартбитов.

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

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

Копирование машин Hyper-V

Импорт машин Hyper-V одновременно является и функционалом по их копированию. Если нам нужно создать клон точный машины, мы не сможем поступить так, как с перемещением — просто взять и в проводнике скопировать файлы машины, а потом перерегистрировать её. У клона должен быть свой уникальный идентификатор оборудования, чтобы иметь собственный внутренний IP в сети. Запускаем функцию импорта, указываем папку хранения исходной машины, из которой мы хотим сделать клон.

Жмём «Далее».

На этапе выбора типа импорта выбираем копирование машины.

Создаём на диске папку для файлов клона и прописываем эти пути на следующем этапе мастера импорта.

Далее указывать путь хранения диска машины-клона. Для него можно создать по пути хранения файлов клона специальную подпапку.

Жмём «Готово».

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

А чтобы не путать его с оригиналом, можем переименовать машину.

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

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

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

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

    

    

    

    

    

    

    

    

    

    

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

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

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

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

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

Перенос машин Hyper-V

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

После запуска операции экспорта указываем путь, куда будут сохранены файлы машины, и жмём «Экспорт».

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

Жмём «Далее».

Указываем путь хранения перемещённых или экспортированных файлов машины.

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

Выбираем тип импорта — регистрация машины по месту.

Жмём «Готово».

Всё – машина импортирована.

Высокая доступность (HA) и управление ресурсами

	VMware vSphere 6.0 Enterprise Plus	Microsoft Hyper-V 2012 R2 Datacenter
Узлов на кластер	64	64
ВМ на кластер	8000	8000
HA (рестарт ВМ при отказе)	VMware HA	Да (кластеризация и Heartbeat)
Отказоустойчивость (Fault Tolerance)	Да (100% доступность для бизнес-критичных приложений в ВМ), даже при аппаратном отказе	Нет
Репликация	Нативная (vSpare Replication)	Hyper-V Replica
Автоматическое управление ресурсами	Планировщик Distributed Resource Scheduler (DRS) для балансирования нагрузки	Dynamic Optimization
Пулы ресурсов	Да	Да (Host Group)
Совместимость миграции	Да (улучшенная совместимость vMotion); EVC в настройках DRS	Да (для процессоров)

Восстановление бэкапа и WDS

1. Если у вас загрузчик RE загружается на Hyper-V виртуальной машине по сети, но не работает клавиатура в ней. Поздравляю, ваш RE образ для WinXP или древнее и не знает о существовании Hyper-V драйверов.
2. Если у вас система начинает восстанавливать бэкап, но останавливается. Удалите все разделы на жестком (на котором восстанавливается бэкап) и попробуйте заново. Только не забывайте, что бэкап может быть битый и после удаления всех разделов на жестком у вас может ничего не остаться от старой информации.
3. Если бэкап с загрузкой UEFI, а вы хотите восстановить на комп без UEFI, то не стоит тратить время. Скорее всего развернуть бэкап не получится.
4. Бэкап с загрузкой UEFI и разделами GPT можно восстанавливать на машины с другим процессором / материнкой, а вот с разделами MBR формата и с загрузкой обычного BIOS на другой машине развернуть вряд ли получится. Ну у меня точно не получалось.
5. Если бэкап пытаться развернуть на диск с меньшим объемом, то сделать это не получится. Даже если диск в бэкапе был почти пуст. В этом случае помогает восстановление на виртуальную машину с динамическим диском. Далее уменьшение этого диска и создание нового бэкапа. Но такое можно только с загрузчиком UEFI в бэкапе (почему, читаем предыдущий пункт).
6. Стоит перед восстановлением бэкапа отключить лишние диски, чтобы не затереть информацию на них.

Рекомендации По Настройке Сети Hyper-V

Теперь, когда мы рассмотрели основы Hyper-V networking, виртуальные коммутаторы, требования к сети кластера Hyper-V, а также новые функции, найденные в виртуальной сети Windows Server 2019.

Давайте рассмотрим ключевые рекомендации по созданию сетей Hyper-V, которые следует учитывать при проектировании и создании инфраструктуры Hyper-V.

По возможности установите или обновите до последней версии Windows Server. С каждым выпуском Windows Server появляются новые и расширенные возможности, связанные с Hyper-V
Используйте современные физические сетевые карты, поддерживаемые корпорацией Майкрософт и имеющие возможность использовать удаленный прямой доступ к памяти (RDMA)
Убедитесь, что вы используете новейшие драйверы сетевых карт и прошивку
Используйте очередь виртуальных машин или сетевые карты с поддержкой VMQ – это обеспечивает преимущества аппаратной виртуализации, которые позволяют более эффективно подключаться к сети для TCP / IP / iSCSI и FCoE
Использование высокоскоростных сетей между узлами Hyper-V в кластере Hyper – V-используйте не менее 10 сетей GbE между узлами Hyper-V для обеспечения соответствия требованиям к пропускной способности и производительности между узлами кластера
Включить jumbo frames-Jumbo frames обеспечивает более эффективную сетевую связь в высокопроизводительных приложениях, поскольку позволяет увеличить количество кадров передачи и снизить загрузку процессора на хостах. Гигантские кадры обычно имеют размер 9000 байт или больше, в отличие от стандартного размера 1500-байтового кадра Ethernet
Не используйте разгрузку TCP Chimney или разгрузку IPsec с Windows Server 2016. Эти технологии устарели в Windows Server 2016 и могут повлиять на производительность сервера и сети

Чтобы отключить разгрузку TCP Chimney, из командной строки с повышенными правами выполните следующие команды:Netsh int tcp show global – показывает текущие настройки TCPnetsh int tcp set global chimney=disabled-отключает разгрузку TCP Chimney, если она включена
Убедитесь, что вы используете избыточные пути между узлами кластера Hyper-V, чтобы убедиться, что при сбое в одном пути существует другой путь, который можно использовать для связи
Планируйте свои сети Hyper – V-особенно с кластерами Hyper-V, планирование сетей очень важно. Убедитесь, что вы подготовили отдельные диапазоны IP-адресов/подсети, VLAN и т

д., для ваших специфичных для кластера сетей (живая миграция, кластер, хранилище, сети виртуальных машин)
Не используйте ReFS с общими томами кластера (CSV) – в настоящее время при использовании с CSV ReFS заставляет кластер работать в режиме перенаправления файловой системы, который отправляет все операции ввода-вывода по сети кластера на узел координатора Тома. Это может значительно повлиять на производительность
Понимание кластерной сети и ее использования – вы должны включить несколько сетей для кластерной связи, так как это обеспечивает встроенную устойчивость к кластерной связи, помогая обеспечить HA этой важной сетевой связи в кластере Hyper-V
Разрешите доступ к операционной системе управления только в тех сетях, которые необходимы. Поймите, как это создает специализированные сетевые соединения на узле Hyper-V
Используемая конвергентная сеть-конвергентная сеть позволяет гораздо эффективнее использовать физические адаптеры на хосте Hyper-V, а также доступную полосу пропускания.
Used Switch Embedded Teaming – With Switch Embedded Teaming позволяет создавать команду с помощью виртуального коммутатора вместо использования физической команды
При использовании Windows Server 2019 используйте Коалесценцию сегмента приема (RSC) для повышения производительности виртуальных рабочих нагрузок
С Windows Server 2019 используйте зашифрованные сети – это позволяет шифровать все сетевые коммуникации в виртуальных сетях для шифрования в полете

Код события 21125

Описание

Сбой настройки конфигурации для динамической миграции на целевом узле.

Действие

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

Решение

Вот как устранить эту проблему:

1. Откройте консоль диспетчера Hyper-V на исходном и целевом узлах.
2. Выберите виртуальная сеть Manager.
3. Проверьте, совпадают ли имена виртуальных сетей между исходным и целевым узлами. Имена виртуальных коммутаторов должны совпадать.
4. Нажмите кнопку «ОК», чтобы виртуальная сеть диспетчера.
5. Щелкните правой кнопкой мыши виртуальную машину на исходном узле и выберите пункт «Параметры».
6. Проверьте, настроена ли виртуальная машина для использования правильной виртуальной сети.
7. Нажмите кнопку » ОК», чтобы закрыть окно «Параметры виртуальной машины «.
8. Закройте консоль диспетчера Hyper-V на исходном и целевом узлах.
9. Откройте консоль диспетчера отказоустойчивости кластеров на исходном узле.
10. Разверните роли и выберите виртуальную машину.
11. На панели действий щелкните » Дополнительные действия>» для обновления конфигурации виртуальной машины.
12. Выполните динамическую миграцию виртуальной машины на целевом узле.

Виртуальная Сеть Hyper-V

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

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

Бэкап изнутри виртуальных машин

1.1. Бэкап сегодняшнего дня

Причем, для серверных и настольных (клиентских) Windows бэкапы формируются разные. И разница заключается в том, что для серверных ОС у нас получатся снимки каждого бэкапа, а вот для настольных — снимок останется всегда только последний. Спросите, а что это за такой инкрементальный бэкап? А «инкрементальный» он остается, потому чтоТо есть для серверной Windows снимки остаются тоже только последние.Позже, выявил, что нет никакой разницы в работе wbadmin на серверной и клиентской ОС. Разве, что разница есть в интерфейсе. wbadmin производит инкрементальный бэкап (кроме первого бэкапа), если указан жесткий диск в ключе -backupTarget (команда использует ключ по умолчанию -vssСopy). Или производит полный бэкап, если добавить ключ -vssFull.

Симптомы

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

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

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

Примечание.

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

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

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

Настройка ограниченного делегирования с помощью оснастки «Пользователи и компьютеры»

1. Откройте оснастку «Active Directory — пользователи и компьютеры». (В диспетчер сервера выберите сервер, если он не выбран, нажмите кнопку «Сервис>>Пользователи и компьютеры Active Directory».

   

   

   

   

   

   

   

   

   

   

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

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

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

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

6. Нажмите кнопку Добавить.

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

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

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

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

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

10. На вкладке Делегирование диалогового окна «Свойства» убедитесь, что службы, выбранные на предыдущем шаге, указаны как службы, которым конечный компьютер может представлять делегированные учетные данные. Нажмите кнопку ОК.

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

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

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

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

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

• Учетная запись пользователя с разрешением на выполнение различных действий. Членство в локальной группе администраторов 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, если на исходном или целевом сервере не установлены средства, и вы запустите эти средства с сервера.

Алгоритм миграции P2V в Vmware

• Для того, чтобы вы могли преобразовать ваш сервер в виртуальную машину Vmware, вам нужно поставить VMware vCenter Converter Standalone 5.5 описано подробно тут.
• Далее подготовить ESXI хост, куда вы будите виртуализовывать физический сервер
• Запустить конвертер и пройти все этапы мастера преобразования

Запускаем VMware vCenter Converter Standalone 5.5, либо уже есть версия поновее 6.2.

Если выскочит ошибка A File I/O error occurred while accessing, то посмотрите из-за чего она происходит

Как виртуализовать физический сервер с помощью VMware vCenter Converter Standalone 5.x.x-01

Выбираем Convert machine

Как виртуализовать физический сервер с помощью VMware vCenter Converter Standalone 5.x.x-02

• Powered-on machine, работающий компьютер или сервер. Это основной метод работы VMware converter,  «без прерывания работы». Сервер может быть физическим или виртуальным. Находиться в локальной сети или быть локальным (та машина, на которую установлен конвертер). Операционная система Windows или Linux, не Unix. Для Linux сильно ограниченный список операционных систем.
• VMware Infrastructure virtual machine, в случае, если нужно виртуальную машину со старой платформы(Virtual Center 2.5, ESX(i) 2-4.1),  перевести на новую, пятую. Основное изменение в 5-ой версии VMware vSphere это новая версия виртуального оборудования за номером 8, вместе с ним изменились и VMware tools.
• VMware Workstation or other Virtual Machine. Workstation очень популярен среди администраторов и часто виртуальная машина из тестовой превращается во временную рабочую. Конвертер перенесет ее на ESXi, в среду vSphere без проблем. Выбираем так же этот пункт, если виртуальные машины работают у вас на VMware Fusion, VMware Player, VMware server 2.x
• Backup image or third-party virtual machine. Восстановление из имеющегося бэкапа или виртуальной машины другого производителя. Восстановление из резервной копии – это очень полезная функция и я ниже расскажу почему.
• Hyper-V server. Для перехода с платформы Microsoft на VMware. Отличается от  third-party virtual machine тем, что у вас должен иметься работающий сервер Hyper-V и подключаться конвертер будет к нему. Виртуальные машины должны быть выключены.

Для работы VMware Converter с Windows like операционной системой по схеме  «Powered-on machine» нужны учетные данные администратора системы, чтобы конвертер мог подключиться, установить агента и начать миграцию. Для Linux систем нужно ввести пароль root и иметь возможность подключаться удаленно по SSH. Возможно, понадобиться поправить конфигурационный файл sshd и разрешить root вход. Еще для входа root должен быть в группе wheel.

VMware Converter при корректном подключении определяет, какую операционную систему ему предстоит мигрировать. Сколько и какие у нее диски и разделы, сколько сетевых интерфейсов, оперативной памяти, процессоров. Все эти данные будут использованы для создания новой виртуальной машины на ESXi хосте. Я вбиваю адрес vCenter и учетные данные.

Как виртуализовать физический сервер с помощью VMware vCenter Converter Standalone 5.x.x-03

Игнорирую предупреждение на сертификат

Как виртуализовать физический сервер с помощью VMware vCenter Converter Standalone 5.x.x-04

Выбираем папку проекта для мигрируемой машины

Как виртуализовать физический сервер с помощью VMware vCenter Converter Standalone 5.x.x-05

Следующий шаг. Указываем хост ESXi на котором будет запущена виртуальная машина. Хранилище, куда будут записаны файлы ВМ и версию виртуального оборудования (10-ая это последняя, на текущий момент). Подозреваю, что если бы я указал в качестве «Destination system vCenter server», то выбор был бы больше, чем из одного варианта. Отобразились бы все доступные хосты и data store

Как виртуализовать физический сервер с помощью VMware vCenter Converter Standalone 5.x.x-06

На следующей странице можно задать какие диски нужно конвертировать какие нет, сколько нужно сетевых интерфейсов и многое другое.

Как виртуализовать физический сервер с помощью VMware vCenter Converter Standalone 5.x.x-07

Смотрим сводку

Как виртуализовать физический сервер с помощью VMware vCenter Converter Standalone 5.x.x-08

Finish. Теперь если посмотреть vCenter, там появился задача создания виртуальной машины.

Как виртуализовать физический сервер с помощью VMware vCenter Converter Standalone 5.x.x-09

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

Как виртуализовать физический сервер с помощью VMware vCenter Converter Standalone 5.x.x-10

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

1. Для начала зайдем в Hyper-V manager и откроем правым кликом настройки Hyper-V. В настройках Live Migration укажем адреса сетевых интерфейсов, к которым будет обращаться гипервизор: 
2. Заглянем в Advanced features. Нас интересуют оба пункта: протокол аутентификации и транспорт, который используют наши ВМ.
   • 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 – адаптером удаленного прямого доступа к памяти. Это полезно для ускорения переноса кластеров. 
3. 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.

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

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

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

1. Для начала зайдем в Hyper-V manager и откроем правым кликом настройки Hyper-V. В настройках Live Migration укажем адреса сетевых интерфейсов, к которым будет обращаться гипервизор: 
2. Заглянем в Advanced features. Нас интересуют оба пункта: протокол аутентификации и транспорт, который используют наши ВМ.
   • 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 – адаптером удаленного прямого доступа к памяти. Это полезно для ускорения переноса кластеров. 
3. 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.

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

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

Код события 21024

Описание

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

Действие

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

Решение

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

Проверьте, находятся ли исходная и целевая виртуальные сети в одной подсети. Если это не так, выполните командлет ipconfig /renew , чтобы возобновить сетевое подключение. Кроме того, можно назначить виртуальной машине новый IP-адрес, если используется статический IP-адрес.