Перенос виртуальной машины hyper v на физический сервер: как перенести виртуальные машины Hyper-V, да побыстрее / Блог компании DataLine / Хабр
как перенести виртуальные машины Hyper-V, да побыстрее / Блог компании DataLine / Хабр
«Любишь Hyper-V – люби и PowerShell»
Первое правило Сообщества Hyper-V в Телеграм
«А если любишь VMware ESXi, то люби PowerShell на пару с ESXi CLI и REST API»
Дополнено мной
Живая миграция (live migration) – популярная функция в Hyper-V. Она позволяет переносить работающие виртуальные машины без видимого простоя. В сети много инструкций по переносу ВМ, но многие из них устарели. Вдобавок не все заглядывают в расширенные настройки и правильно используют возможности Live Migration.
Я собрал нюансы и неочевидные параметры для быстрого переноса ВМ внутри кластера и между кластерами. Заодно поделюсь маленькими секретами в настройке и проектировании. Надеюсь, статья будет полезна начинающим админам.
Дисклеймер: Все описанные шаги желательно сделать ДО ввода сервера Hyper-V в прод. Hyper-V никогда не прощает ошибок проектирования и подведет вас при первом удобном случае. То есть уже на следующий день.
Вспоминаем матчасть
Как обычно происходит миграция ВМ с одного узла на другой внутри кластера Hyper-V:
- Конфигурация ВМ копируется с одного узла кластера на другой.
- Страницы памяти виртуальной машины помечаются для копирования на целевой хост, и начинается процесс их перемещения в режиме онлайн.
- Поскольку виртуальная машина все еще работает, страницы памяти постоянно меняются. Во время миграции Hyper-V отслеживает измененные страницы памяти и переносит их на другой хост. Процесс повторяется до тех пор, пока на первом узле кластера не останется только несколько измененных страниц.
Копирование страниц памяти с одного узла на другой и их синхронизация.
- ВМ на исходном хосте выключается, оставшиеся страницы памяти копируются на целевой хост, и виртуальная машина на нем включается. Переключение происходит за доли секунды. Процесс достаточно быстрый, чтобы ни один клиент не заметил простоя.
Это и называется живой миграцией. Схема справедлива для любого гипервизора.
Чем больше оперативной памяти у ВМ и чем интенсивнее она изменяется, тем дольше будет переезд. Поэтому трафик живой миграции требует хорошего канала и тщательной настройки.
По такой схеме работает классическая живая миграция внутри Failover Cluster. Для нее нужен общий том CSV, поданный всем хостам кластера.
Помимо этого есть второй вид Live Migration, живая миграция в режиме «ничего общего» (Shared-Nothing Live Migration). Этот сценарий обычно используется для миграции ВМ без простоя между кластерами. Помимо страниц памяти с одного хоста Hyper-V на другой копируется диск VHD(X) с переносом и синхронизацией дельты данных, записанных на него.
Разберем основные нюансы по настройке интерфейсов.
Задаем настройки протоколов
- Для начала зайдем в Hyper-V manager и откроем правым кликом настройки Hyper-V. В настройках Live Migration укажем адреса сетевых интерфейсов, к которым будет обращаться гипервизор:
- Заглянем в 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 – адаптером удаленного прямого доступа к памяти. Это полезно для ускорения переноса кластеров.
- Authentication protocol: по умолчанию установлен протокол CredSSP – Credential Security Support Provider Protocol. Он прост в использовании, но, если в инфраструктуре несколько кластеров, мы не сможем перенести ВМ между кластерами.
- 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:
Set-SmbServerConfiguration -EncryptData $false -RejectUnencryptedAccess $false
Так мы совершим меньше действий при передаче трафика и не потратим лишнее время на шифрование. В случае с кластерами оно может нам понадобиться.Эти же настройки в более модном 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-нодам и количество физических ядер на каждом процессоре.
Посмотрим на процесс пошагово
- Для начала опишем сети, которые будем использовать. Предположим, у нас стандартная двухпортовая on-board сетевая карта и двухсокетная материнская плата.
- Создать SET через стандартный интерфейс можно с помощью Virtual Switch в VMM (Virtual Machine Manager). Если VMM нет, выполняем следующий скрипт PowerShell на каждом хосте Hyper-V:
New-VMSwitch -Name "SET" –NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $True -AllowManagementOS $true -MinimumBandwidthMode Weight
В результате мы создадим свитч с менеджмент-интерфейсом. 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-VMSwitchTeam "SET" -LoadBalancingAlgorithm Dynamic
Здесь нужно быть очень внимательным, особенно если мы создаем SET через SC VMМ и оставляем балансировку Host Default. В Windows Server 2016 алгоритмом по умолчанию был Dynamic. В Windows Server 2019 дефолтный алгоритм по непонятным причинам изменили на Hyper-V Port, так что можно и ошибиться. - Когда мы создали свитч, IP-адрес первого физического интерфейса мигрирует на виртуальный интерфейс свитча.
После этого мы создаем сетевые интерфейсы по количеству физических портов на сетевой карте и «прибиваем» CSV-трафик и трафик живой миграции к каждому порту:
# Создаем виртуальные сетевые адаптеры Live Migration Add-VMNetworkAdapter –ManagementOS –Name "LiveMigration01" –SwitchName MGMT-Switch -NumaAwarePlacement $true Add-VMNetworkAdapter –ManagementOS –Name "LiveMigration02" –SwitchName MGMT-Switch -NumaAwarePlacement $true # Задаем VLAN Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "LiveMigration*" -VlanId 2 -Access #Задаем IP-адреса для адаптеров New-NetIPAddress –InterfaceAlias "vEthernet (LiveMigration01)" -IPAddress 192.168.2.2 -PrefixLength 24 -Confirm:$false New-NetIPAddress –InterfaceAlias "vEthernet (LiveMigration02)" -IPAddress 192.168.2.3 -PrefixLength 24 -Confirm:$false # Создаем виртуальные сетевые адаптеры CSV-трафика Add-VMNetworkAdapter –ManagementOS –Name "CSV01" –SwitchName MGMT-Switch -NumaAwarePlacement $true Add-VMNetworkAdapter –ManagementOS –Name "CSV02" –SwitchName MGMT-Switch -NumaAwarePlacement $true # Задаем VLAN Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "CSV*" -VlanId 3 -Access # Задаем IP-адреса для адаптеров New-NetIPAddress –InterfaceAlias "vEthernet (CSV01)" -IPAddress 192.168.3.2 -PrefixLength 24 -Confirm:$false New-NetIPAddress –InterfaceAlias "vEthernet (CSV02)" -IPAddress 192.168.3.3 -PrefixLength 24 -Confirm:$false - Теперь мы должны утилизировать все доступные нам оффлоады. Например, я выкручиваю Jumbo Frames до 9K для всех типов трафика, кроме Management.
Тут без помощи сетевых инженеров не обойтись: потребуется настройка портов на сетевом оборудовании.
Set-NetAdapterAdvancedProperty -Name "NIC1" -DisplayName "Jumbo Packet" -DisplayValue 9014 Set-NetAdapterAdvancedProperty -Name "NIC2" -DisplayName "Jumbo Packet" -DisplayValue 9014 Set-NetAdapterAdvancedProperty -Name "vEthernet (CSV01)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes" Set-NetAdapterAdvancedProperty -Name "vEthernet (CSV02)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes" Set-NetAdapterAdvancedProperty -Name "vEthernet (LiveMigration01)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes" Set-NetAdapterAdvancedProperty -Name "vEthernet (LiveMigration02)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"
Названия свойств сильно зависят от модели сетевой карты, так как это не статические фичи Windows Server, а фичи конкретной модели сетевой карты. Чтобы использовать эти фичи, нужно ОБЯЗАТЕЛЬНО ставить драйверы от производителя сетевой карты и ни в коем случае не использовать стандартный драйвер Windows. Иначе сразу после создания SET может отвалиться сеть по Management’у. Список всех свойств сетевой карты можно получить через командлет Get-NetAdapterAdvancedProperties. - Проверим, что метрики сетевых интерфейсов равны:
Синхронизируем метрики интерфейсов и снизим приоритет интерфейсов CSV-трафика. В моем случае задавал так:
Set-NetIPInterface -InterfaceIndex 16 -InterfaceMetric 10000 Set-NetIPInterface -InterfaceIndex 3 -InterfaceMetric 10000 Set-NetIPInterface -InterfaceIndex 9 -InterfaceMetric 10500 Set-NetIPInterface -InterfaceIndex 6 -InterfaceMetric 10500
Это нужно, чтобы трафик равномерно распределялся между физическими портами на равных. - Если карта поддерживает RDMA, то трафик живой миграции уместно перенести на нее. RDMA позволяет двум хостам обмениваться данными в их памяти без обращения к ОС хостов и без нагрузки на CPU. Поддержку RDMA на карте проверяем с помощью командлета Get-NetAdapterRdma.
Пример: что можно получить с помощью командлета. Скрин со statemigration.com.
При этом сетевые ворклоады машин лучше оставить на встроенном или внешнем адаптере без RDMA (но, опять же, эта тема дискуссионная).
- На сетевую производительность влияет расстояние до сокета процессора от конкретного порта и PCI-шины. Поэтому перейдем к маппингу виртуальных адаптеров и настройке Virtual Machine Queues (VMQ).
Маппинг необходим, чтобы трафик гарантированно выходил из определенного сетевого порта и не произошла ситуация, когда все сетевые нагрузки уходят в один случайный порт.
Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC1" -VMNetworkAdapterName "LiveMigration01" Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC2" -VMNetworkAdapterName "LiveMigration02" Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC1" -VMNetworkAdapterName "CSV01" Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC2" -VMNetworkAdapterName "CSV02" - Настройка VMQ помогает учесть расположение на PCI-шине. По умолчанию, очереди обрабатываются нулевым ядром нулевого процессора. Это не очень хорошо: во-первых, мы его ОЧЕНЬ сильно греем, во-вторых, так мы просто не сможем выжать из сетевого порта больше 3 Гб. Это относится к трафику ВМ. Но у нас же другой трафик (SMB)! Значит, имеет смысл настроить RSS.
До Windows Server 2019 настройка VMQ была обязательна, пока не появился dVMMQ. Он автоматически балансирует трафик и перекидывает его с ядра на ядро, как только нагрузка доходит 90%. Так что на Windows Server 2019 сидеть и высчитывать ядра для VMQ не нужно.
Настраиваем так:
Set-NetAdapterRss -Name "NIC1" -BaseProcessorGroup 0 -BaseProcessorNumber 2 -MaxProcessors 8 -MaxProcessorNumber 16 Set-NetAdapterRss -Name "NIC2" -BaseProcessorGroup 0 -BaseProcessorNumber 16 -MaxProcessors 8 -MaxProcessorNumber 30
Посмотрим наглядно, как это работает. Предположим, у нас есть 2 процессора с 16 физическими ядрами. Это 32 логических ядра с учетом многопоточности. Открываем Excel и выписываем по порядку ядра от 0 до 31:Для первого порта сетевого адаптера назначаем Base Processor Number 2. Для количества ядер берем степень двойки. В четвертой степени получим 16 – это значение задаем для MaxProcessorNumber.
BaseProcessor для второго адаптера тоже будет равен 16 (опять берем степень двойки). На картинке хорошо виден перехлест для обработки трафика на шестнадцатом ядре. Ситуация не критичная, так как нулевое ядро мы разгрузили и не используем для обработки Live Migration.
Через эти же командлеты можно задать и количество RSS-очередей (RSS Queues). Их количество зависит от конкретной модели сетевой карты, поэтому перед настройкой RSS Queues нужно изучить документацию к сетевой карте.
Настраиваем миграцию для кластеризованного сценария
Со стороны Failover Cluster дополнительно выкрутим настройки таймаутов кластера:
(Get-Cluster).SameSubnetDelay = 2000
(Get-Cluster).SameSubnetThreshold = 30
- SameSubnetDelay указывает, сколько раз в какое время мы посылаем хартбиты. По умолчанию он выставлен в 1 секунду.
Если узлы кластера находятся в одной сети, этого достаточно. Если они в разных сетях, то нужно настроить CrossSubnetDelay с теми же значениями.
- SameSubnetThreshold показывает, сколько хартбитов мы можем максимально пропустить. По дефолту это 5 хартбитов, максимум – 120. Мы поставим оптимальное значение – 30 хартбитов.
Для высоконагруженных машин важно выкрутить оба параметра. Если не уложимся, то с большой вероятностью такая машинка не переедет.
Чтобы трафик живой миграции использовался только на определенной сети, также оставим отдельную сеть в настройках Failover Cluster:
Собственно, это и есть минимальный джентльменский набор настроек для корректной работы Live Migration в Hyper-V.
Перенос виртуальной машины на физическую – Сайт ARNY.RU
Итак, нужно было перенести виртуальную, предварительно настроенную и оттестированную Ubuntu 16.04 из Hyper-V на физический машину. Опасался «подводных камней», с которыми столкнулся при обратном переносе, отличие — ОС была Windows. Оказалось, всё прозрачно.
Последовательность переноса
Первое что нужно — выключить виртуальную машину и скопировать vhd-шник.
Второе — открутить диск от физической машины и подцепить к машине, на которой будет выполняться перенос. Для подобных операций очень рекомендую купить USB док-станцию. У меня вот такая и очень ей доволен, удобно:
Далее, для переноса воспользовался программой Vhd2Disk
Программа абсолютно проста и настолько же эффективна. Посмотреть соответствие дисков можно в Управление дисками:
Перенос 5Gb прошел менее чем за 10 минут без всяких проблем. После загрузки оказалось только, что сетевой интерфейс стал вместо eth0 — eno1. Почему так происходит почитать можно здесь. Поэтому данный интерфейс не был автоматически включен. Команда ifconfig выводит только активные интерфейсы. Посмотреть все интерфейсы, включая отключенные:
ifconfig -a
Стартовать интерфейс:
ifconfig eno1 up
Настроить новый сетевой интерфейс на автостарт:
vi /etc/network/interfaces
Настройка на DHCP:
iface eno1 inet dhcp auto eno1
Настройка на статику:
iface eno1 inet static address 192.168.0.1 netmask 255.255.255.0 gateway 192.168.0.254 dns-nameservers 192.168.0.254 8.8.8.8 auto eno1
Тут же, если что, можно прикрутить статический маршрут:
up route add -net 192.168.21.0 netmask 255.255.255.0 gw 192.168.0.254 или up route add -net 192.168.21.0 netmask 255.255.255.0 eno1 или up route add -net 192.168.21.0 netmask 255.255.255.0 gw 192.168.0.254 eno1
В зависимости от того, как указан способ достижения сети назначения, создаётся один из трёх возможных типов маршрута:
- Маршрут следующего перехода — указывается только IP адрес следующего перехода;
- Напрямую подключённый статический маршрут — указывается только выходной интерфейс;
- Полностью заданный статический маршрут — указываются IP адрес следующего перехода и выходной интерфейс.
Для интерфейсов типа точка-точка можно использовать статические маршруты, указывающие на выходной интерфейс или адрес следующего перехода. Для многоточечных или широковещательных интерфейсов рекомендуется использовать статические маршруты, указывающие на адрес следующего перехода.
От себя добавлю, что если сетевой интерфейс один, то eго можно указывать независимо от типа подключения.
Ну и до кучи — посмотреть список маршрутов:
netstat -n -r
Посмотреть список оборудования:
lspci
Посмотреть информацию о процессоре:
lscpu
Раньше использовал VirtualBox для полигона и экспериментов, теперь всё проще — Hyper-V встроен в Windows 10 Pro и есть простой инструмент для переноса.
Импорт и экспорт в Hyperv или перенос виртуальных машин
Импорт и экспорт в Hyper V это возможность копирование и переноса виртуальных машин. Эта возможность используется в тестовой среде, когда у нас есть образ или шаблон машины и для переноса с одного сервера на другой. Я так же слышал, что кто-то использует эту возможность как резервное копирование. Мы рассмотрим на примерах с GUI и в Powershell.
Если вы хотите создать шаблон виртуальной машины, то перед экспортом нужно сделать sysprep. Что бы просто перенести виртуальную машину Hyper V этого делать не надо.
Sysprep — это утилита сброса уникальных идентификаторов. Когда в одной сети находятся машины с одинаковыми идентификаторами могут быть ошибки и конфликты. После сброса идентификаторов нужно будет заново устанавливать те данные, которые требуются при первой установке Windows. Я бы крайне рекомендовал делать эту операцию во избежание проблем. Вы можете запустить эту команду из CMD:
%WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe
Либо запустить файл sysprep.exe в этой папке:
C:\Windows\System32\Sysprep
И подтвердить действия с этими настройками:
После окончания работы утилиты компьютер выключится и его нельзя будет включать. Если вы его включите, то идентификаторы сгенерируются и операцию нужно будет проделывать заново.
Экспорт Hyper V
Теперь выполним экспорт виртуальной машины Hyper V, в этот момент ВМ может быть включена. Нажмите на нее правой кнопкой и найдите кнопку экспорта:
Выберете путь, куда хотите экспортировать ВМ и нажмите кнопку подтверждения. ВМ будет экспортирована со всеми настройками и виртуальным диском:
После этого мы выполнили в Hyper V копирование виртуальной машины.
Импорт Hyper V
Что бы выполнить в Hyper V импорт виртуальной машины нажмите следующую кнопку:
После стартового окна нам нужно будет выбрать папку, куда мы экспортировали ВМ:
Проверяем, что имя ВМ совпадает с той, которую мы хотим импортировать:
На следующем окне у нас появляется три возможных пункта клонирования виртуальной машины Hyper V. Так как ВМ тоже имеет уникальные идентификаторы этот пункт очень важен:
- Регистрировать виртуальную машину по мету (Register the virtual machine in-place) — если файлы ВМ уже находятся там, где они должны и вы не планируете переносить их в новое место. Это может быть ВМ с подключенной флешки или iSCSI диска. В этом случае уникальный идентификатор не генерируется.
- Восстановить виртуальную машину (Restore the virtual machine) — в отличие от предыдущего пункта все файлы переносятся в новое место, которые вы укажете в следующем окне. Уникальный идентификатор так же остается прежним.
- Копировать виртуальную машину (Copy the virtual machine) — копирует ВМ с новым сгенерированным идентификатором. В следующем окне нужно будет указать куда копировать эти файлы. Этот случай используется когда мы используем шаблон ВМ.
Если в этот момент уже работает ВМ с этим идентификатором, то мы получим ошибку:
The operation failed because a virtual machine with the same identifier already exists. Select a new identifier and try the operation again.
Ошибка загрузки конфигурации виртуальной машины hyper v
Я выполню копирование машины, но остальные варианты аналогичны:
В случае с копированием мы можем выбрать новое расположение файлов чекпоинтов, конфигураций и кэша либо использовать установленное по умолчанию:
В этом окне выбирается расположение диска:
В этой ВМ адаптер подключен к другому коммутатору и его не существует на этом хосте гипервизора. Проверка коммутаторов идет по именам и если раньше коммутатор, на этом же хосте, назывался ‘Ext 1’, а затем был удален или переименован на ‘Ext 01’ вы тоже получите ошибку. Можно выбрать новый коммутатор или пропустить этот шаг:
На последнем шаге мы проверяем введенные данные и нажимаем кнопку подтверждения:
После этого ВМ импортируется и вам может понадобится подключиться к коммутатору и переименовать ее.
В обоих случаях вам нужно зайти в настройки ВМ:
Для переименовывания машины нужно зайти на вкладку «Имя»:
Если сетевых адаптеров у ВМ нет, то нужно зайти во вкладку добавления устройств и добавить сетевой адаптер:
А затем подключить к коммутатору:
После этого в Hyper V виртуальная машина будет подключена и ее можно запускать.
Экспорт и импорт виртуальной машины Hyper V в Powershell
Все команды имеют ключ ComputerName, а значит перенос виртуальной машины Hyper V может делаться на удаленном компьютере.
Получим список ВМ Hyper V, что бы узнать какую машину экспортировать:
Get-VM
Что бы через консоль Powershell в Hyper V скопировать виртуальную машину, в базовом варианте, нужно сделать следующее:
Export-VM -Name 'CentOS' -Path 'C:\VMimported\'
Где:
- Name — имя ВМ, которую экспортируем
- Path — путь, где будет лежать копия виртуальной машины Hyper V
Так как мы можем выполнить клонирование и включенной машины, то у нас есть несколько способов манипулировании с памятью. Для этого есть ключ CaptuteLiveState, которого нет в версии Windows Server 2012 r2 и ниже, со значениями:
- CaptureSavedState — включает оперативную память
- CaptureDataConsistentState — используется Production checkpoint
- CaptureCrashConsistentState — память не сохраняется
По умолчанию используется CaptureSavedState.
Export-VM -Name 'CentOS' -Path 'C:\VMimported\' -CaptureLiveState CaptureCrashConsistentState
Для импорта есть три варианта сохранения идентификаторов, которые описывались выше.
Если вы решили импортировать ВМ, которая уже находиться в нужной папке и с сохранением идентификаторов сделайте так:
Import-VM -Path "C:\wii\CentOS\Virtual Machines\8EA3B8C0-611B-48EF-8344-392FA71D89B6.vmcx"
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.
Для импорта ВМ, с сохранением идентификаторов, но в новое место на диске выполните:
Import-VM -Path 'C:\VMimported\CentOS\Virtual Machines\8EA3B8C0-611B-48EF-8344-392FA71D89B6.vmcx' -VhdDestinationPath 'C:\NewPath\' -VirtualMachinePath 'C:\NewPath\' -Copy
Где:
- VhdDestinationPath — куда будет скопирован виртуальный диск Hyper V
- VirtualMachinePath — куда будут скопированы файлы конфигурации виртуально машины
- Copy — указывает, что это операция копирования
Дополнительные ключи:
- SnapshotFilePath — куда будут скопированы чекпоинты
- SmartPagingFilePath — куда будет скопирован файл подкачки
Можно не указывать каждый тип файлов, а просто указать файл конфигурации в Path и действие Copy — тогда ВМ будет скопирована в местоположение указанное в настройках Hyper V.
В случае копирования VM с генерированием нового идентификатора можно сделать так:
Import-VM -Path "C:\wii\CentOS\Virtual Machines\8EA3B8C0-611B-48EF-8344-392FA71D89B6.vmcx" -Copy -GenerateNewId
В этом случае все файлы будут перемещены в папку, которая была указана в настройках Hyper V. Операция клонирования выполнена.
…
Теги:
#powershell
Экспорт и импорт виртуальной машины Hyper-V – WindowsTips.Ru. Новости и советы
Механизм экспорта-импорта в гипервизоре Hyper-V предназначен для перемещения виртуальных машин с одного компьютера или сервера на другой. Экспорт – это, по сути, копирование виртуальной машины с полным сохранением ее конфигурации. При экспорте копируется виртуальный жесткий диск, настройки оборудования, сохраненный момент работы гостевой ОС, созданные контрольные точки (снапшоты).
Механизм экспорта-импорта Hyper-V также можно использовать для создания на том же сервере или на том же компьютере виртуальной машины-клона для тестирования и взаимодействия с виртуальной машиной-оригиналом. Машина-клон может получить другой ID (идентификатор), другой внутренний IP-адрес в сети Hyper-V, вследствие чего, по сути, не будет ничем отличаться от виртуальных машин, созданных с нуля.
Ниже рассмотрим процесс экспорта-импорта виртуальной машины на примере Hyper-V, входящего в состав Windows 10, детальнее.
Рассматриваемые вопросы:
- Экспорт виртуальной машины
- Экспорт снимка виртуальной машины
- Надежность формата экспорта Hyper-V
- Импорт виртуальной машины
1. Экспорт виртуальной машины
Одним из преимуществ новой версии Hyper-V, вошедшей в состав Windows Server 2012 R2, клиентских систем Windows 8.1 и 10, является способность осуществлять некоторые ресурсоемкие задачи, в частности, экспорт на лету, в процессе работы виртуальной машины, без ее остановки, даже без приостановки. Экспорт осуществляется в фоновом режиме, он проходит не быстро, поскольку задействует небольшое количество системных ресурсов, оставляя пользователю возможность работать с виртуальной машиной дальше.
Как осуществляется экспорт виртуальной машины? Выбираем в диспетчере Hyper-V нужную виртуальную машину, вызываем контекстное меню. Нам нужна команда «Экспорт».
Далее используем кнопку обзора и указываем путь хранения файлов экспорта. Жмем «Экспорт».
2. Экспорт снимка виртуальной машины
Еще одна относительно новая функция Hyper-V, которой не было в старых серверных версиях Windows – возможность экспорта отдельной контрольной точки, то есть, виртуальной машины в состоянии на момент создания этой контрольной точки. Ранее гипервизор Microsoft предусматривал только экспорт-импорт всей виртуальной машины. И в случае, если нужно было состояние какой-то отдельной контрольной точки, приходилось экспортировать виртуальную машину со всеми ее контрольными точками, а после импорта делать откат к нужной. Сейчас Hyper-V позволяет экспортировать каждую отдельную контрольную точку. Экспортировав отдельный снапшот, его можно затем импортировать как новую виртуальную машину, в частности, со своим уникальным идентификатором на том же сервере или компьютере.
Чтобы осуществить экспорт виртуальной машины из контрольной точки, выбираем в диспетчере Hyper-V и машину, и контрольную точку. На последней вызываем контекстное меню и выбираем «Экспорт».
3. Надежность формата экспорта Hyper-V
Экспорт виртуальной машины Hyper-V осуществляется не в какой-нибудь отдельный сжатый формат файла, куда помещаются и виртуальный жесткий диск, и файлы конфигурации, и сохраненное состояние гостевой ОС, как, например, это предлагается механизмом экспорта-импорта в программе VirtualBox. В случае с виртуальными машинами VirtualBox экспорт-импорт возможен при участии посредника – файла формата OVA. При повреждении этого файла импорт виртуальной машины VirtualBox может не состояться. А вот в случае с Hyper-V экспорт виртуальной машины означает полное копирование виртуального жесткого диска в исходном его формате – VHDX (или VHD).
Таким образом, если прочие данные экспорта повредятся, виртуальную машину все равно можно будет воссоздать. Нужно будет средствами Hyper-V создать новую виртуальную машину, использовав существующий файл VHDX (VHD).
4. Импорт виртуальной машины
Экспортированную виртуальную машину в дальнейшем можно импортировать в совместимой версии Hyper-V в составе серверных редакций Windows и клиентских Windows 8.1 и 10.
Для импорта виртуальной машины выбираем соответствующую функцию в диспетчере Hyper-V.
Жмем «Далее» в окне приветствия мастера.
В следующем окне используем кнопку обзора и указываем путь к папке с экспортированной виртуальной машиной. Жмем «Далее».
Выбираем нужную виртуальную машину, если в указанной папке их несколько. Жмем «Далее».
Затем нужно сделать выбор, как будет импортирована виртуальная машина. Если таковая перенесена с другого сервера или компьютера, можно использовать первый тип импорта, предусматривающий ее регистрацию с использованием исходного идентификатора. Этот вариант регистрирует виртуальную машину в той же папке, где хранятся файлы ее экспорта, следовательно, не будет затрачено время на копирование файлов.
Второй тип импорта также подойдет для случаев переноса виртуальной машины с другого сервера или компьютера, но при его использовании экспортированные файлы будут перенесены в указанную папку. Идентификатор виртуальной машины при этом останется прежним.
Если виртуальная машина перемещается в рамках одного сервера или компьютера, следует использовать третий тип импорта, предусматривающий генерирование нового идентификатора. Ведь на одном физическом компьютере не может быть виртуальных машин Hyper-V с одинаковым идентификатором.
В нашем случае имеет место быть копирование виртуальной машины, это третий тип импорта. Жмем «Далее».
Путь хранения файлов конфигурации, контрольных точек и прочих данных импортируемой виртуальной машины, указанный Hyper-V по умолчанию, можно сменить. Необходимо установить галочку смены места хранения и вручную указать нужные пути.
В нашем случае просто допишем в пути (через слеш) создание отдельной папки «Копия». Жмем «Далее».
Этот же путь укажем и для файла VHDX, чтобы все находилось в одном месте. Жмем «Далее».
Завершающий этап мастера – сводка данных импорта. Жмем «Готово».
Теперь в нашем случае в диспетчере Hyper-V имеется две одинаковые виртуальные машины. Они с разными идентификаторами, но у них одно и то же название. Сменим название только что импортированной виртуальной машины.
Все – процесс импорта осуществлен. Импортированную виртуальную машину можно запускать и тестировать.
Перенос сервера в среду виртуализации Hyper-V – Сайт ARNY.RU
Хочу поделиться своим опытом переноса. Нужно было перенести Windows 2008 Enterprise в среду Hyper-V. Сначала предполагал использовать утилиту Disk2vhd, но потом был установлен Acronis Backup Advanced и я воспользовался его встроенной возможностью при создании бекапа конвертировать бекап в виртуальную машину. Для этого достаточно при настройке свойств задания резервного копирования для пункта «Преобразование в виртуальную машину» выбрать Преобразовать, затем выбрать тип машины и месторасположение, где будут созданы файлы.
После выполнения этого задания создался vhd-файл и файл настроек. Добавил в диспетчере Hyper-V новую виртуальную машину и указал данный vhd-файл. Машина нормально загрузилась. Может быть лучше было выполнить импорт виртуальной машины, а не просто создать машину и затем подцеплять vhd. В дальнейшем уже пользовался именно импортом, где это возможно.
Не всегда импорт возможен. Так при импорте между хостами Hyper-V 2008/2008 R2 проблем нет, но если переносить с хоста Hyper-V 2008/2008 R2 на хост Hyper-V 20012 R2 и выше — непосредственно при самом импорте не будет найдено доступных машин для импорта. Решение такое:
- Выключить виртуальные машины (VM) на хосте Hyper-V 2008/2008 R2;
- Остановить службу Hyper-V Virtual Machine Management Service (VMMS) на хосте 2008/2008 R2;
- Скопировать папки VM на хост Hyper-V Windows Server 2012 R2;
- Импортировать.
Между Hyper-V 2012 R2/2016 и обратно ещё пока импортировать VM не пробовал.
Проблемы
Далее оказалось, что не пробрасывается на виртуальную машину мышь. При попытке работы мышью в окне виртуальной машины через Подключение к виртуальной машине Hyper-V сразу появлялось сообщение — «ввод с помощью мыши не перенаправлен». Первое найденное решение было переустановить службы интеграции внутри гостевой ОС:
но это ничего не дало. Далее при просмотре Диспетчера устройств обнаружилось, что устройство шина VMBus с восклицательным знаком, а состояние устройства — «Не найдены свободные ресурсы, которые устройство может использовать». Помогла эта статья MS. После выполнения указанных в статье действий и перезагрузки, сразу заработала мышь, появилась виртуальная сетевая карта и виртуальный видеоадаптер.
Дальше — нет доступа к сети, искал, искал, нашёл — криво создался виртуальный коммутатор (в Hyper-V 2008 R2, куда осуществлялся перенос, он называется Виртуальная сеть ), оказывается и такое бывает 🙂
Следующая трабла — не подключается сеанс RDP с других машин. Нашёл — в Конфигурации служб терминалов, в свойствах подключения (имя по умолчанию TCP-RDP), на вкладке Сетевой адаптер — пусто, и сразу выпрыгивает ошибка — «Средству настройки узла сеансов не удалось получить свойства этого подключения. Подключение удалено или его внутреннее состояние повреждено», выбрать новый адаптер при этом нельзя, удалить подключение тоже нельзя — ошибка. Удалось удалить через реестр по адресу:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal server\WinStations
Отсюда понятно, что перед конвертацией сервера в виртуальную машину эту настройку нужно снять с конкретного сетевого адаптера и выставить настройку — «Все сетевые адаптеры настроены для этого протокола»:
Ну и последний пункт переноса — удаление лишних теперь программ и драйверов.
Выводы
Перед переносом:
- Для Windows 2008 в msconfig отметить чекбокс «Определить HAL»;
- Если это сервер RDP, то в Конфигурации служб терминалов выставить «Все сетевые адаптеры настроены для этого протокола».
При соблюдении этих условий перенос пройдем максимально гладко.
Следующим этапом планирую опробовать для архивирования виртуальных машин прекрасный по отзывам Veem Backup Free Edition.
Добавление от 19.11.2016
Переносил ещё одну машину — уже под управлением Windows XP на хост Hyper-V. Теперь уже воспользовался программой Disk2vhd. Программа использует теневое копирование и очень легко и просто создаёт образ прям с работающей машины. Можно выбрать конвертацию как в vhd, так и в более новый vhdx. После переноса та же проблема — неправильный драйвер уровня аппаратных абстракций HAL, поэтому нет виртуальных устройств и не работает мышь. Опция Disk2vhd «Подготовить машину к переносу в виртуальную среду» не помогла, опции «Определить HAL», которая есть в Windows 2008, в Windows XP нет. Решилось установкой служб интеграции, ещё можно попробовать напрямую указать HAL в Boot.ini, это же делает и опция «Подготовить машину к переносу в виртуальную среду», но драйвер она подписывает неправильный. Должно быть, как я понял:
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows XP" /HAL=hal.dll
Как переместить виртуальную машину Hyper-V 3.0
Добрый день уважаемые читатели блога, я продолжаю знакомить вас с виртуализацией на базе 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 это не замена отказоустойчивого кластера, рассматривайте ее как дополнение, которое позволяет подготавливать инфраструктуру к созданию кластера, она вам поможет например в случае, когда один из серверов ломается, и нужно мигрировать без простоя виртуальные машины.
Требования live migration
Давайте определимся, что необходимо для успешного перемещения виртуальной машины на Hyper-V 3.0:
- Логично, что нам нужно минимально два хоста виртуализации, первый это источник перемещения, а второй, хост назначения.
- У хоста назначения, должно хватать ресурсов, чтобы принять виртуальную машину
- Обязательное требование, это процессоры должны быть одного семейства, если у вас процессор intel, то перевезти на AMD у вас не получиться, такие же ограничения были и у vMotion Vmware
- Сетевое подключение между хостами Hyper-V 3.0, желательно должно быть 1 гб/сек, можно даже под это дело выделить отдельную сетевую карту с другим VLAN ID.
- В некоторых случаях виртуальные коммутаторы на обоих хостах должны называться одинаково, чтобы избежать ошибок перемещения.
И так на первом хосте, у меня есть виртуальная машина с именем dc7, ее я хочу переместить на другой хост Hyper-V. Для этого щелкаем по ней правым кликом и выбираем переместить.
первое окно мастера можно сразу пропускать, оно не несет ни какой полезности.
Далее у вас два варианта перемещения:
- Переместить виртуальную машину (перемещение виртуальной машины и (при необходимости) ее хранилища на другой хост) > вариант полного переезда хранилища и всей виртуальной машины на другой сервер.
- Переместить хранилище виртуальной машины (Перемещение только хранилища виртуальной машины в другое расположение на этом сервере или в общее хранилище) > тут два варианта, либо вы хотите ее перевезти на другой локальный диск (разгрузить нагрузку, например), либо в общий диск, для подключения хоста к отказоустойчивому кластеру.
Следующим шагом, будет указание сервера, на который вы перевозите, так как у меня сервера, являются членами домена, то я делаю это через поиск по нему.
Далее вас спросят:
- Переместить данные виртуальной машины в одно расположения > я обычно выбираю этот вариант, все в одной папке
- Переместить данные виртуальной машины в указанное место > разбить по папкам
- Переместить только виртуальную машину > этот вариант при общей шаре, когда виртуальные диски трогать не нужно, а нужно перенести, только конфигурацию виртуалки
Далее задаем папку сохранения.
Все начинается процедура перемещения, если у вас не включена динамическая миграция, то вы можете получить ошибку 0x8009030E, посмотрите как она решается.
Хочу напомнить, что на момент перемещения, ваш виртуальный сервер будет доступен, можете проверить, через команду пинг.
В диспетчере задач, можно про мониторить загрузку сети при перемещении.
Как видите в процессе живой миграции на хостах Hyper-V 3.0, без общего хранилища, нет ничего сложно, в принципе все понятно на интуитивном уровне и Microsoft, с каждым релизом упрощает жизнь системным администраторам.
Еще раз про живую миграцию: как перенести виртуальные машины Hyper-V, да побыстрее
Как настроить перенос работающих ВМ без простоя внутри кластера и между кластерами.
29 июля •
Евгений Парфенов
“Любишь Hyper-V – люби и PowerShell”
© Первое правило Сообщества Hyper-V в Телеграм
“А если любишь VMware ESXi, то люби PowerShell на пару с ESXi CLI и REST API”
© Дополнено мной
Живая миграция (live migration) – популярная функция в Hyper-V. Она позволяет переносить работающие виртуальные машины без видимого простоя. В сети много инструкций по переносу ВМ, но технология развивается, а туториалы устаревают. Вдобавок не все заглядывают в расширенные настройки и правильно используют возможности Live Migration.
Поводом для статьи стала инструкция для Hyper-V 3.0. В своем материале покажу, как изменилась настройка с тех пор.
Я собрал нюансы и неочевидные параметры для быстрого переноса ВМ внутри кластера и между кластерами. Заодно поделюсь маленькими секретами в настройке и проектировании. Надеюсь, статья будет полезна начинающим админам.
Дисклеймер: Все описанные шаги желательно сделать ДО ввода сервера Hyper-V в прод. Hyper-V никогда не прощает ошибок проектирования и подведет вас при первом удобном случае. То есть уже на следующий день.
Вспоминаем матчасть
Как обычно происходит миграция ВМ с одного узла на другой внутри кластера Hyper-V:
- Конфигурация ВМ копируется с одного узла кластера на другой.
- Страницы памяти виртуальной машины помечаются для копирования на целевой хост, и начинается процесс их перемещения в режиме онлайн.
- Поскольку виртуальная машина все еще работает, страницы памяти постоянно меняются. Во время миграции Hyper-V отслеживает измененные страницы памяти и переносит их на другой хост. Процесс повторяется до тех пор, пока на первом узле кластера не останется только несколько измененных страниц.
Копирование страниц памяти с одного узла на другой и их синхронизация
- ВМ на исходном хосте выключается, оставшиеся страницы памяти копируются на целевой хост, и виртуальная машина на нем включается. Переключение происходит за доли секунды. Процесс достаточно быстрый, чтобы ни один клиент не заметил простоя.
Это и называется живой миграцией. Схема справедлива для любого гипервизора.
Чем больше оперативной памяти у ВМ и чем интенсивнее она изменяется, тем дольше будет переезд. Поэтому трафик живой миграции требует хорошего канала и тщательной настройки.
По такой схеме работает классическая живая миграция внутри Failover Cluster. Для нее нужен общий том CSV, поданный всем хостам кластера.
Помимо этого есть второй вид Live Migration, живая миграция в режиме “ничего общего”, или Shared-Nothing Live Migration. Этот сценарий обычно используется для миграции ВМ без простоя между кластерами. Помимо страниц памяти с одного хоста Hyper-V на другой копируется диск VHD(X) с переносом и синхронизацией дельты данных, записанных на него.
Разберем основные нюансы по настройке интерфейсов.
Задаем настройки протоколов
- Для начала зайдем в Hyper-V manager и откроем правым кликом настройки Hyper-V. В настройках Live Migration укажем адреса сетевых интерфейсов, к которым будет обращаться гипервизор: