Еще раз про живую миграцию: как перенести виртуальные машины Hyper-V, да побыстрее
Живая миграция (live migration) – популярная функция в Hyper-V. Она позволяет переносить работающие виртуальные машины без видимого простоя. В сети много инструкций по переносу ВМ, но многие из них устарели. Вдобавок не все заглядывают в расширенные настройки и правильно используют возможности Live Migration.
Я собрал нюансы и неочевидные параметры для быстрого переноса ВМ внутри кластера и между кластерами. Заодно поделюсь маленькими секретами в настройке и проектировании. Надеюсь, статья будет полезна начинающим админам.
Вспоминаем матчасть
Как обычно происходит миграция ВМ с одного узла на другой внутри кластера Hyper-V:
- Конфигурация ВМ копируется с одного узла кластера на другой.
- Страницы памяти виртуальной машины помечаются для копирования на целевой хост, и начинается процесс их перемещения в режиме онлайн.
- Поскольку виртуальная машина все еще работает, страницы памяти постоянно меняются. Во время миграции Hyper-V отслеживает измененные страницы памяти и переносит их на другой хост. Процесс повторяется до тех пор, пока на первом узле кластера не останется только несколько измененных страниц.
Чем больше оперативной памяти у ВМ и чем интенсивнее она изменяется, тем дольше будет переезд. Поэтому трафик живой миграции требует хорошего канала и тщательной настройки.
По такой схеме работает классическая живая миграция внутри Failover Cluster. Для нее нужен общий том CSV, поданный всем хостам кластера.
Помимо этого есть второй вид Live Migration, живая миграция в режиме «ничего общего» (Shared-Nothing Live Migration). Этот сценарий обычно используется для миграции ВМ без простоя между кластерами. Помимо страниц памяти с одного хоста Hyper-V на другой копируется диск VHD(X) с переносом и синхронизацией дельты данных, записанных на него.
Разберем основные нюансы по настройке интерфейсов.
Задаем настройки протоколов
-
Для начала зайдем в Hyper-V manager и откроем правым кликом настройки Hyper-V. В настройках Live Migration укажем адреса сетевых интерфейсов, к которым будет обращаться гипервизор:
-
Authentication protocol: по умолчанию установлен протокол CredSSP – Credential Security Support Provider Protocol. Он прост в использовании, но, если в инфраструктуре несколько кластеров, мы не сможем перенести ВМ между кластерами.
Возможность использовать этот протокол появилась в Windows Server 2016. SMB по умолчанию отдает трафик в несколько портов (SMB Multi-channel). Также он прекрасно работает с RDMA – адаптером удаленного прямого доступа к памяти. Это полезно для ускорения переноса кластеров.
Начиная с Windows Server 2016, службы работают в контексте NETWORK SERVICE, который не может имперсонироваться в AD. Так что в этом случае выбираем неограниченное делегирование (Unconstrained Delegation), но учитываем, что это довольно небезопасно:
Так мы совершим меньше действий при передаче трафика и не потратим лишнее время на шифрование. В случае с кластерами оно может нам понадобиться.
Эти же настройки в более модном Windows Admin Center:
Разбираемся с конфигурацией сети
Сетевая оптимизация Hyper-V – это крайне дискуссионная тема в сообществе и безграничное поле для экспериментов (предела совершенству в нем нет по определению). Так что перед пошаговой настройкой сети разберемся, как технологии изменились за последнее время и как можно это использовать.
Как было раньше. Старые мануалы по переносу ВМ Hyper-V описывают сценарии с использованием технологии тиминга Load Balancing/Fail Over (LBFO). LBFO позволяла группировать физические сетевые адаптеры и создавать поверх них интерфейсы. Но были и минусы, например: не было поддержки RDMA, нельзя было выяснить, через какой порт тима будет идти трафик. А поскольку трафик живой миграции требует довольно жирного канала, это превращалось в проблему, когда все сетевые ворклоады ломились в один физический порт.
Как сейчас. В Windows Server 2019 даже нельзя создать виртуальный свитч поверх LBFO Team. Единственным поддерживаемым решением для объединения портов сетевой карты в Hyper-V остался Switch Embedded Team (SET).
SET агрегирует адаптеры, как и vSwitch у ESXi. Физические сетевые порты становятся патч-кордом для разных типов трафика (в том числе для ВМ), а поверх них нарезаются виртуальные интерфейсы.
Тут нужно добавить, что в типах гипервизоров есть небольшой рассинхрон. Англоязычные авторы считают, что есть только 2 типа, но на самом деле их 3 (подробно мы с коллегами описывали их в этом посте). Когда-то гипервизоры ESX были гибридного типа (1+). Это был такой модернизированный Red Hat c ролью гипервизора. VMware ушла от этого в vSphere 4.1 и стала честным гипервизором типа 1 (bare-metal).
Microsoft взяла опыт VMware на вооружение и реализовала Switch Embedded Team в Windows Server 2016. Эта схема показывает большую производительность и гибкость в управлении трафиком в рамках тиминга.
В новых версиях SET позволяет создавать разные виртуальные интерфейсы для разных нагрузок поверх группы физических интерфейсов. По сути, это виртуальные сетевые адаптеры корневого раздела, которыми мы можем управлять наподобие виртуальных адаптеров ВМ.
Как это влияет на процесс настройки. В Hyper-V, помимо менеджмент-интерфейса, мы обычно создаем интерфейсы для живой миграции и интерфейсы для CSV-трафика кластера. Для этого нам нужно знать количество сетевых портов, входящих в SET, – именно столько виртуальных интерфейсов нужно будет создать. Также учитываем расположение сетевых портов на PCI-шине, количество сокетов для последующего маппинга интерфейсов по NUMA-нодам и количество физических ядер на каждом процессоре.
Посмотрим на процесс пошагово
-
Для начала опишем сети, которые будем использовать. Предположим, у нас стандартная двухпортовая on-board сетевая карта и двухсокетная материнская плата.
Имя сети | Назначение | Сеть | Шлюз | VLAN ID | Количество виртуальных адаптеров |
Management | Управляющий интерфейс | 192.168.1.0/24 | 192.168.1.1 | 0 (Native) | 1 |
LiveMigration | Живая миграция | 192.168.2.0/24 | 2 | 2 | |
CSV | CSV-трафик | 192.168.3.0/24 | 3 | 2 |
В результате мы создадим свитч с менеджмент-интерфейсом. MinimumBandwidthMode обязательно сразу задаем как weight, иначе после создания SET мы не сможем изменить этот параметр. Так пропускная способность сети будет указана в относительных числах. Это понадобится для настройки Network QoS Policies (а иначе они не будут работать).
После этого мы создаем сетевые интерфейсы по количеству физических портов на сетевой карте и «прибиваем» CSV-трафик и трафик живой миграции к каждому порту:
Тут без помощи сетевых инженеров не обойтись: потребуется настройка портов на сетевом оборудовании.
Синхронизируем метрики интерфейсов и снизим приоритет интерфейсов CSV-трафика. В моем случае задавал так:
Пример: что можно получить с помощью командлета. Скрин со statemigration.com.
Маппинг необходим, чтобы трафик гарантированно выходил из определенного сетевого порта и не произошла ситуация, когда все сетевые нагрузки уходят в один случайный порт.
До Windows Server 2019 настройка VMQ была обязательна, пока не появился dVMMQ. Он автоматически балансирует трафик и перекидывает его с ядра на ядро, как только нагрузка доходит 90%. Так что на Windows Server 2019 сидеть и высчитывать ядра для VMQ не нужно.
Посмотрим наглядно, как это работает. Предположим, у нас есть 2 процессора с 16 физическими ядрами. Это 32 логических ядра с учетом многопоточности. Открываем Excel и выписываем по порядку ядра от 0 до 31:
Для первого порта сетевого адаптера назначаем Base Processor Number 2. Для количества ядер берем степень двойки. В четвертой степени получим 16 – это значение задаем для MaxProcessorNumber.
BaseProcessor для второго адаптера тоже будет равен 16 (опять берем степень двойки). На картинке хорошо виден перехлест для обработки трафика на шестнадцатом ядре. Ситуация не критичная, так как нулевое ядро мы разгрузили и не используем для обработки Live Migration.
Настраиваем миграцию для кластеризованного сценария
Со стороны Failover Cluster дополнительно выкрутим настройки таймаутов кластера:
-
SameSubnetDelay указывает, сколько раз в какое время мы посылаем хартбиты. По умолчанию он выставлен в 1 секунду.
Чтобы трафик живой миграции использовался только на определенной сети, также оставим отдельную сеть в настройках Failover Cluster:
Собственно, это и есть минимальный джентльменский набор настроек для корректной работы Live Migration в Hyper-V.
Клонирование, импорт и экспорт виртуальных машин в Hyper-V
06.10.2022
itpro
Hyper-V, PowerShell, Windows Server 2016, Виртуализация
комментариев 20
В 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 варианта регистрации ВМ на хосте:
- Register the virtual machine in-place (use the existing unique ID) —зарегистрировать ВМ в каталоге с импортируемыми файлами, ID ВМ сохраняется;
- Restore the virtual machine (use the existing unique ID) — скопировать файлы ВМ в другой каталог, сохранить исходный идентификатор ВМ;
- Copy the virtual machine (create a new unique ID) — скопировать ВМ в другую каталог и сгенерировать новый ID.
Если вы попробуете импортировать ВМ с дублирующим ID, появится ошибка:
Чтобы создать клон ВМ с новым ID мы выбрали 3 вариант. Мастер предложит указать в каких каталогах нужно разместить файлы ВМ. По умолчанию, используются каталоги, заданные в настройках хоста Hyper-V.
Затем укажите каталог для хранения виртуальных дисков vhdx ВМ.
После этого новая клонированная виртуальная машина появится в консоли Hyper-V.
Клонирование ВМ через экспорт/импорт в Hyper-V с помощью PowerShell
Рассмотрим, как клонировать виртуальную машину Hyper-V через импорт/экспорт из консоли PowerShell.
Для экспорта ВМ воспользуйтесь такой командой:
Export-VM -Name win10 -Path ‘C:\VHD\export’
Если вы хотите экспортировать запущенную ВМ, вы можете использовать параметр CaptuteLiveState, в котором определяется как нужно копировать оперативную память ВМ. Доступны три опции
- CaptureSavedState – экспортировать оперативную память (по-умолчанию);
- CaptureDataConsistentState – экспортировать состояние ВМ из Production checkpoint;
- CaptureCrashConsistentState – не сохранять содержимое памяти.
Export-VM -Name win10 -Path ‘C:\VHD\export’ -CaptureLiveState CaptureCrashConsistentState
Если вы хотите экспортировать состояние ВМ в определеном снимке, нужно указать его имя.
Сначала выведите список снимков для указанной ВМ:
Get-VMSnapshot -VMName win10
Затем выполните экспорт нужного снимка по его имени:
Export-VMSnapshot -Name “win10 — (2/17/2021 — 9:52:20 PM) Standard” -VMName win10 -Path ‘C:\VHD\export’
После завершения экспорта ВМ вы можете импортировать ее. Если нужно зарегистрировать ВМ по месту хранения файлов, выполните команду:
Import-VM -Path «C:\VHD\export\win10\Virtual Machines\1117A061-0B50-4BC2-850C-88CCD4C114FB.vmcx»
В параметре Path указываем расположение vmcx файла конфигурации ВМ (формат vmcx заменил XML формат конфигурационных файлов ВМ в Hyper-V Server 2016). Для копирования ВМ в другой каталог с тем же ID используйте параметр Copy. Чтобы сгенерировать нового идентификатор ВМ, используйте параметр GenerateNewId:
Import-VM -Path «C:\VHD\export\win10\Virtual Machines\1117A061-0B50-4BC2-850C-88CCD4C114FB.vmcx» -VhdDestinationPath «C:\VHD\win10_2» -VirtualMachinePath «C:\VHD\win10_2»
В параметре 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 новой ВМ и переименуйте ее:
Затем для удобства можно переименовать виртуальный жесткий диск.
Get-VHD -VMId 24ad8934-f650-46f6-9caa-2a3b79b79bd5| Select Path | Rename-Item -NewName win10_2.vhdx
Remove-VMHardDiskDrive -VMName win10_2 -ControllerType SCSI -ControllerLocation 0 -ControllerNumber 0
Add-VMHardDiskDrive -VMName win10_2 -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 0 -Path «C:\VHD\win10_2\win10_2.vhdx»
Изменим MAC адрес виртуального адаптера (можно указать новый статический MAC или настроить динамическое получение MAC адреса).
Set-VMNetworkAdapter -VMName win10_2 -DynamicMacAddress
Start-VM -Name win10_2
Прежде, чем подключить новую ВМ в сеть, желательно переименовать ее и изменить IP адрес на новый (если используется DHCP адресация, этот шаг можно пропустить). В данном случае мы можем подключиться к новой ВМ через PowerShell Direct с помощью командлета Invoke-Command или Enter-PSSession:
Enter-PSSession -ComputerName win10_2 -Credential (Get-Credential)
Rename-Computer win10_2
Remove-NetIPAddress -InterfaceAlias “Ethernet” -AddressFamily IPV4
New-NetIPAddress -IPAddress 192.168.31.50 -InterfaceAlias “Ethernet” -AddressFamily IPv4 -PrefixLength 24
Restart-Computer
Клонирование виртуальных машин Hyper-V через Windows Admin Center
Возможно клонировать ВМ Hyper-V напрямую без промежуточного экспорта/импорта появилась в Windows Admin Center v2009.
Запустите WAC, выберите раздел Virtual Machines, выберите ВМ -> Manage -> Clone.
Затем нужно указать имя новой ВМ и каталог, в который нужно поместить ее файлы.
Обратите внимание, что мастере клонирования есть опция “I have already run sysprep on my VM”. Если вы не выполнили генерализацию образа с помощью Sysprep, и не включили эту опцию, Hyper-V создаст снапшот исходной ВМ, выполните ее Sysprep и склонирует в новую (исходная ВМ будет несколько раз перезагружена и не доступна для работы). После этого исходная ВМ будет возвращена в первоначальное состояние, а снапшот удален.
Дождитесь окончания клонирования ВМ. Новой ВМ автоматически будет присвоен новый ID.
Предыдущая статья Следующая статья
alt=»включить Enable single-root I/O virtualization (SR-IOV) для виртуального коммутатора hyper-v» width=»58″ height=»56″ /> Включаем поддержку SR-IOV для виртуальных машин Hyper-V
alt=»Новые настройки Get-NetTCPSetting в Windows Server 2019″ width=»58″ height=»56″ /> Низкая скорость сети на хосте Hyper-V с Windows Server 2019
alt=»ignoreHeadless=TRUE — добавить параметр при установке vmware esxi» width=»58″ height=»56″ />Установка VMWare ESXi в виртуальную машину Windows Hyper-V
alt=»назначить ip адреса шлюзов hyper-v коммутаторам» width=»58″ height=»56″ />Маршрутизация между разными IP подсетями в Hyper-V
А какие есть бесплатные способы сделать клон ВМ из ESXi в Hyper-V?
Из приличных был StarWind V2V Converter, вроде это функционал там бесплатные. можно еще тулзой disk2vhd
«зарегистрировать ВМ по хранения файлов» — что это?
Отсуствие грамотного редактора для вычитки
речь про «по месту хранения файлов»
Copy и GenerateNewId вместе. Не ошибка?
Очень интересует последний способ, спасибо за него! Я поставил Windows Admin Center, она отлично встала на Windows Server 2022, я попробовал клонировать Windows 10 (заведено 2 юзера, оба админы).
Вот какую ошибку получаю:
Подробная информация об уведомлении
Ошибка
Не удалось клонировать виртуальную машину
00:43:25
Источник
Перейти в Виртуальные машины
Тип
Ошибка
Сообщение
Не удалось клонировать виртуальную машину «Win10_1». Ошибка: «Sysprep could not be completed.2021-12-11 00:39:41, Error SYSPRP Package Microsoft.LanguageExperiencePackru-RU_19041.28.77.0_neutral__8wekyb3d8bbwe was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.2021-12-11 00:39:41, Error SYSPRP Failed to remove apps for the current user: 0x80073cf2.2021-12-11 00:39:41, Error SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.2021-12-11 00:39:41, Error SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing ‘SysprepGeneralizeValidate’ from C:\Windows\System32\AppxSysprep.dll; dwRet = 0x3cf22021-12-11 00:39:41, Error SYSPRP SysprepSession::Validate: Error in validating actions from C:\Windows\System32\Sysprep\ActionFiles\Generalize.xml; dwRet = 0x3cf22021-12-11 00:39:41, Error SYSPRP RunPlatformActions:Failed while validating Sysprep session actions; dwRet = 0x3cf22021-12-11 00:39:41, Error [0x0f0070] SYSPRP RunDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 0x3cf22021-12-11 00:39:41, Error [0x0f00d8] SYSPRP WinMain:Hit failure while pre-validate sysprep generalize internal providers; hr = 0x80073cf2»
В образе установлен Microsoft.LanguageExperiencePackru-RU_19041.28.77.0_neutral__8wekyb3d8bbwe. На этом прилжении падает sysprep.
Нужно удалить его:
_https://docs.microsoft.com/en-us/troubleshoot/windows-client/deployment/sysprep-fails-remove-or-update-store-apps
Хотелось бы поинтересоваться, как можно победить следующую проблему. Из-за расплодившихся снапшотов, на физическом диске закончилось место и виртуалка не запустилась. Перенес один из виртуальных дисков на другой физический диск. Система запустилась, преждевременно спросив где тот самый диск. Теперь все работает, но место может закончиться.
Клонировать систему не дает, перенести не дает, и удалить снапшоты тоже не дает.
Подскажите как решить проблему? Можно ли скопировать всё на внешний диск и путем подмены букв дисков запустить виртуалку? И если можно, то как отключить службу hyper-v на время подмены букв?
Спасибо, надеюсь на ответ
Вот так не дает переместить файлы ВМ?
Move-VMStorage «VMname» -DestinationStoragePath «FullPathtothenewfolder»
Я так понимаю эту команду можно запустить при работающей машине? Или желательно отключить?
Ошибка выходит
Move-VMStorage: Не удалось выполнить операцию, так как файл не найден.
Move-VMStorage позволяет делать онлайн миграцию. другая проблема в том, что если виртуальный диск во времея миграции нагружен из гостевой ВМ, это может занять дополнительное время иил просто не хватит места для хранения изменнеия.
файл не найден — проверьте путь к файлам
Почему не видит работающую машину?
PS C:\Users\IMorozov> Export-VM -Name POSTER -Path ‘E:\Hyper-V\_EXPORT\POSTER’
Export-VM : Недопустимый параметр. Hyper-V не удалось найти виртуальную машину с именем POSTER.
строка:1 знак:1
+ Export-VM -Name POSTER -Path ‘E:\Hyper-V\_EXPORT\POSTER’
+
+ CategoryInfo : InvalidArgument: (POSTER:String) [Export-VM], VirtualizationInvalidArgumentException
+ FullyQualifiedErrorId : InvalidParameter,Microsoft.HyperV.PowerShell.Commands.ExportVMCommand
get-vm что возвращает?
Добрый день. Тоже возникает ошибка при экспорте ВМ. В чем может быть проблема? Спасибо.
Export-VM : Не удалось скопировать файл во время экспорта.
строка:1 знак:1
+ Export-VM -Name ‘NetFlowAnalyzer’ -Path ‘E:\Mainserver\NetFlowAn …
+
+ CategoryInfo : NotSpecified: (Microsoft.HyperV.PowerShell.VMTask:VMTask) [Export-VM], VirtualizationOpe
rationFailedException
+ FullyQualifiedErrorId : OperationFailed,Microsoft.HyperV.PowerShell.Commands.ExportVMCommand
Не удается найти описание для идентификатора события 18110 из источника Microsoft-Windows-Hyper-V-VMMS. Вызывающий данное событие компонент не установлен на этом локальном компьютере или поврежден. Установите или восстановите компонент на локальном компьютере.
Если событие возникло на другом компьютере, возможно, потребуется сохранить отображаемые сведения вместе с событием.
К событию были добавлены следующие сведения:
%%2147942401
0x80070001
C:\Hyper-V\Virtual Hard Disks\NetFlowAnalyzer\NetFlowAnalyzer.vhd
E:\Mainserver\NetFlowAnalyzer\NetFlowAnalyzer\Virtual Hard Disks\NetFlowAnalyzer.vhd
Отсутствует специальный ресурс языкового стандарта для нужного сообщения
Добавлю, что некоторые виртуалки экспортнулись, а вот несколько не хотят… в чем проблема я не понимаю.
Попробуйте проверить vhdx диски проблемных машин на ошибки с помощью Test-VHD.
Пробовали экспортировать эту ВМ через Hyper-V GUI? Можем там юудет более понятна ошибка
Через GUI ошибка еще больше неинформативна.
А зачем в случае клонирования через консоль Hyper-V Manager сначала нужно экспортировать? Оно безо всякого предварительного экспорта замечательно импортирует если просто указать папку существующей ВМ, которую нужно клонировать.
Спасибо за ваш вариант. Всё получилось без экспорта. Просто импортировал с уже рабочей виртуалки.
Поскольку клонировал доменный компьютер, то у клонированной виртуалки удалил сетевую карту, вывел из домена, переименовал, сменил SID с помощью программы SIDCHG64 (64-bit Windows), добавил сетевую карту (как раз сменился MAC адрес) и добавил в домен.
/AlexxHost/
Вы попали на блог, целиком и полностью посвященный продуктам компании Microsoft. В основном речь будет идти про системы корпоративных коммуникаций на базе Exchange Server.
вторник, 7 июня 2011 г.
Перемещение виртуальной машины Hyper-V со снапшотами
В жизни бывает такая ситуация, когда необходимо переместить виртуалку в другую локацию, при этом, как можно быстрее и с сохранением для неё всего дерева снапшотов (Snapshot). Штатными средствами решить подобную задачу мы не можем (переместить конечно можем через Экспорт/Импорт, но это долго), так что придется делать все руками. Пред тем как взяться за дело, нужно вникнуть в суть происходящего. Заглянуть внутрь механизма работы Hyper-V, и понять как его можно “обмануть”, нам поможет Александр Станкевич, он же Stanky.
Поехали…
Содержимое папок "C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines" и "C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots" — Soft Link’и на конфигурацию наших виртуальных машин и их Snapshot’ы. Таким образом, создавая/удаляя эти ссылки (XML-файл), мы изменяем список виртуальных машин, и цепочки Snapshot’ов, отображаемые в консоли Hyper-V. Например, это можно использовать для удаления виртуальной машины из списка без выполнения её полного уничтожения, которое включает в себя Merge имеющихся Snapshot’ов (порой, крайне длительная операция). Так же можно изменить путь, где находится наша виртуальная машина — бывает полезно при исправлении ошибок в планировании. Причём создание/удаление можно производить на живой системе (без остановки служб), но учитывая последствия ;).
Для создания ссылки можно воспользоваться утилитой "mklink". Удаление ни чем не отличается от удаления обычного файла. При этом удаляется лишь ссылка, а оригинальный файл остаётся на месте. Чтобы узнать, куда ведёт ссылка, можно воспользоваться "fsutil reparsepoint query" (к выводу отнестись с улыбкой).
Для изменения пути виртуальной машины, необходимо:
1) Остановить службу "Hyper-V Virtual Machine Management" — это позволит нам править конфигурацию виртуальной машины. При этом, все запущенные виртуальные машины продолжают работать.
2) Произвести необходимые изменения путей в конфигурации.
3) Если имеются Snapshot’ы: так как любой Snapshot файловой системы (файл с расширением AVHD) является Differencing-диском, необходимо предварительно записать цепочку (Chain), которой связаны наш виртуальный диск и его Snapshot’ы.
3.1) Находим все файлы с расширением AVHD данной виртуальной машины.
3.2) Меняем расширение на VHD (штатные утилиты работают только с ним).
3.3) Inspect Disk. -> выбираем поочерёдно переименованные файлы -> записываем соотношение строчек "File Name" и "Parent".
4) Изменяем пути в файловой системе.
5) Восстанавливаем цепочку дисков, так как пути изменились: Inspect Disk. -> выбираем поочерёдно наши Snapshot’ы -> Reconnect -> выбираем файл в соответствии с записанным значением в пункте 3.3, после чего меняем расширение у обработанного файла обратно на AVHD.
6) Удаляем старую ссылку на цепочку Shapshot’ов: C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots\%GUID%.xml.
7) Запускаем "cmd" под администратором: mklink "C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots\%GUID%.xml" "%VMSnapshotsNewPath%\%GUID%.xml".
8) Удаляем старую ссылку на конфигурацию виртуальной машины: C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\%GUID%.xml.
9) Запускаем "cmd" под администратором: mklink "C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\%GUID%.xml" "%VMConfigNewPath%\%GUID%.xml"
9) Для работы всего этого хозяйства, необходимы соответствующие NTFS-права доступа, как на символические ссылки, так и к самим файлам виртуальной машины.
9.1) Как вариант, чтоб всё было совсем правильно, можно выполнить экспорт, получившегося варианта, после чего выполнить импорт.
Экспорт и импорт виртуальных машин в Windows Server 2012 R2
Возможность получить точную копию виртуальной машины очень удобно использовать в процессе разработки, тестирования или траблшутинга. В Windows Server 2012 R2 появилось несколько новых возможностей, связанных с экспортом\импортом ВМ, о которых мы и поговорим.
Экспорт
Раньше для того, чтобы экспортировать ВМ штатными средствами, предварительно необходимо было ее остановить. В Windows Server 2012 R2 можно экспортировать запущенные виртуальные машины ″наживую″, прямо в процессе работы. Для экспорта открываем Hyper-V Manager, выбираем нужную ВМ, кликаем на ней правой клавишей мыши и в контекстном меню выбираем «Export».
Указываем расположение, в которое будет производиться экспорт и жмем «Export».
Также для экспорта ВМ из консоли PowerShell можно воспользоваться такой командой:
Export-VM -Name SC3 -Path ″D:\Hyper-V\SC3Clone″
Экспорт снимка ВМ
Раньше для того, чтобы экспортировать снимок (checkpoint), надо было произвести полный экспорт ВМ вместе со всеми снимками, импортировать машину и только затем откатится на нужный снимок. В Windows Server 2012 R2 появилась возможность экспортировать только конкретный снимок виртуальной машины. Для этого выбираем нужную ВМ, переходим в поле «Checkpoints», кликаем правой клавишей на нужном снимке, выбираем «Export» и указываем, куда сохранять файлы.
И то же самое с помощью PowerShell. Выводим список снимков для указанной ВМ:
Get-VMSnapshot -VMName SC3
Выбираем нужный снимок и экспортируем его, например так:
Export-VMSnapshot -Name ′SC3 — (2/25/2014 — 4:03:55 PM)′ -VMName SC3 -Path D:\Hyper-V
Примечание. При создании снимка в качестве его имени по умолчанию берется имя ВМ и время создания. Для удобства экспорта снимкам можно давать вменяемые имена сразу при создании, с помощью команды Checkpoint-VM -SnapshotName . Также снимки можно переименовать командой Rename-VMSnapshot , либо из оснастки Hyper-V Manager.
Импорт
В импорте особых изменений нет. Открываем Hyper-V Manager, кликаем правой клавишей на имени хоста и в контекстном меню выбираем «Import Virtual Machine».
Запускается мастер импорта виртуальных машин. В первом окне жмем Next >
Затем указываем расположение папки с файлами импортируемой ВМ.
Выбираем машину для импорта (в указанной папке могут быть файлы нескольких ВМ).
Выбираем, каким образом производить импорт. Соответственно, есть три варианта:
1) Register the virtual machine in-place — зарегистрировать ВМ по месту с тем-же ID;
2) Restore the virtual machine — скопировать ВМ в другую папку, ID оставить без изменения;
3) Copy the virtual machine — скопировать ВМ в другую папку и сгенерировать для нее новый ID.
Обратите внимание, что у каждой ВМ на хосте Hyper-V есть уникальный идентификатор (ID), т.е. на одном хосте не может быть двух ВМ с одинаковым ID. Выбор варианта зависит от ситуации, так если вы разворачиваете скопированную машину на одном хосте с оригиналом, то подойдет только копирование с новым ID.
Дальше, в зависимости от выбранного варианта импорта либо сначала указываем папки для копирования файлов конфигурации, снимков
и виртуальных дисков ВМ.
Либо просто просматриваем суммарную информацию и жмем «Finish».
Импорт с помощью PowerShell. Для того, чтобы просто зарегистрировать ВМ по месту, надо выполнить команду:
Import-VM -Path ′D:\Hyper-V\SC3\Virtual Machines\4e782fc5-8a82-4311-8627-b69ab2e894f5.xml′
В параметре Path указываем расположение xml-файла конфигурации. Для копирования ВМ в другое место с тем же ID воспользуемся параметром Copy , а для генерации нового идентификатора используем параметр GenerateNewId :
Import-VM -Path ′D:\Hyper-V\SC3\Virtual Machines\4e782fc5-8a82-4311-8627-b69ab2e894f5.xml′ -Copy -GenerateNewId
Проверка на совместимость
Иногда при переносе ВМ на другой хост могут возникнуть проблемы с совместимостью. В этом случае просто импортировать машину не получится, при попытке будет выдана ошибка. Для выяснения причин несовместимости можно воспользоваться командлетом Compare-VM. Вот типичный пример — импорт не удался, в сообщении фигурирует ошибка в конфигурации. Попробуем уточнить, в чем проблема, для чего выведем отчет о совместимости командой:
Compare-VM -Path ′D:\SC3\Virtual Machines\4e782fc5-8a82-4311-8627-b69ab2e894f5.xml′
Как видно из отчета, в строке Incompatibilities стоит код ошибки, что означает проблему с совместимостью.
Для уточнения проблемы еще раз выведем отчет о совместимости и поместим его в переменную:
$report = Compare-VM -Path ′D:\SC3\Virtual Machines\4e782fc5-8a82-4311-8627-b69ab2e894f5.xml′
Затем извлечем причину несовместимости:
$report.Incompatibilities | ft -AutoSize
Как видно из сообщения, проблема в отсутствии на данном хосте виртуального свича с именем Private. Этот свич прописан в конфигурации ВМ, и для успешного импорта его надо оттуда удалить. Сделаем это с помощью команды:
Затем проверим еще раз совместимость:
Compare-VM -CompatibilityReport $report
И поскольку проблема устранена, то импортируем машину командой:
Import-VM -CompatibilityReport $report
Заключение
В заключение напомню о том, что при экспорте мы получаем точную копию виртуальной машины, включая идентификатор безопасности (SID), имя и IP-адрес (при статической адресации). Поэтому, во избежании конфликтов, при развертывании такой машины надо быть крайне осторожным, и делать это желательно в изолированной среде, особенно если виртуальная машина является членом домена AD.
На этот раз все, а в следующей статье мы рассмотрим динамическое клонирование виртуальных машин с помощью Virtual Machine Manager.