Руководство пользователя MIND Migrate #guest 2.16-1

Обзор MIND Migrate #guest

MIND Migrate #guest в составе комплекса MIND Suite предназначен для миграции данных и переноса рабочей нагрузки между платформами.

Традиционные подходы к миграции, например резервное копирование с последующим восстановлением, имеют ограничения: процесс сложен, результаты трудно воспроизвести, возможны человеческие ошибки. Кроме того, сценарии backup&restore требуют значительного времени и приводят к длительным простоям продуктивных сред.

MIND Migrate #guest автоматизирует миграцию: обнаруживает и проверяет источники и приёмники, предоставляет пошаговый мастер настройки параметров без установки дополнительного ПО и единую консоль управления.

Термины и сокращения

Агент: Сервис, который запускается на источнике или приёмнике и взаимодействует с контроллером в процессе настройки и запуска заданий на миграцию или репликацию. Каждый агент имеет уникальный идентификатор и регистрируется на конкретном экземпляре контроллера. Агент получает и выполняет команды с контроллера, ведёт журнал событий, запускает хост-утилиты и отправляет контроллеру информацию о статусе заданий. Может устанавливаться в ручном режиме или автоматически.
Драйвер: Набор бинарных файлов и утилит, необходимых для выполнения миграции или репликации.
Источник (Source): Машина, с которой выполняется копирование (синхронизация) данных на приёмник в процессе выполнения миграции. Источник содержит исходную операционную систему, приложения, данные и настройки, которые переносятся на приёмник.
Ключи доступа (Vault): Учётные данные, используемые для аутентификации и авторизации на машине.
Контроллер: Центральный компонент MIND Suite. Выступает в роли оркестратора для реализации функций управления и контроля за выполнением заданий миграции и репликации, координирует работу компонентов, хранит конфигурацию и предоставляет интерфейс взаимодействия (GUI и API) для пользователей и администраторов. Контроллер устанавливается на выделенный сервер под управлением совместимой ОС Linux и состоит из набора взаимодействующих между собой сервисов, работающих в виде нативных сервисов systemd и внутри контейнеров: API, Scheduler, Vault, Postgres, RabbitMQ и других.
Машина (Unit): Виртуальная машина, физическая рабочая станция или сервер, зарегистрированные на контроллере для использования в качестве источника или приёмника в заданиях миграции или репликации.
Миграционное задание (Set): Объект, включающий в себя заранее описанные настройки и инструкции, которые используются для миграции данных между выбранным источником и приёмником. Включает в себя конфигурацию дисков, настройки сетевых интерфейсов, режим передачи данных, сценарии запуска скриптов на различных этапах выполнения задания, настройки расписания запуска и завершения задания, а также расширенные настройки.
Платформа: Объект, содержащий в себе настройки, включая адрес подключения, ключ доступа, тип платформы, версию API и другие настройки, используемые для подключения к внешней платформе виртуализации или облачному сервису для автоматизации типовых операций по работе с виртуальными машинами.
Приёмник (Target): Машина, на которую выполняется копирование (синхронизация) данных с источника в процессе выполнения миграции. После завершения процесса приёмник содержит копию ОС, данных и приложений, идентичную источнику.
Проект: Контейнер, используемый для логической группировки объектов, используемых в миграции и репликации, таких как машины, задания, сайты, для более удобной организации работы. Проекты могут использовать для разделения объектов по организационному признаку — объекты разных подразделений относятся к разным проектам, по сегментам — объекты внешнего и внутреннего контура, по типу приложений — объекты инфраструктурных приложений, объекты для конкретного бизнес-приложения и т. д.
Размещение (Placement): Контекст, описывающий ресурсы, которые будут использоваться при автоматическом создании машин приёмников. Перечень ресурсов зависит от целевой платформы, на которой создаётся размещение и может включать в себя кластер, пул ресурсов, хранилища для размещения дисков виртуальных машин, сети для подключения сетевых интерфейсов ВМ, набор шаблонов, из которых создаются приёмники, и другие параметры.
Тенант: Логический контейнер в MIND Suite для организации совместной работы пользователей из разных организаций или подразделений на одном контроллере с обеспечением требований по изоляции и конфиденциальности. Тенанты позволяют разграничить зону видимости проектов, машин, заданий и других объектов и предоставлять к ним доступ только для определённой группы пользователей.
Flow: Технология, обеспечивающая периодическую синхронизацию данных с источника на приёмник для обеспечения «тёплой» миграции. Использует механизм Change Block Tracking (CBT) для отслеживания и передачи изменений без остановки приложений на источнике.
KTMU: Kernel Tools with MIND Utilities — загрузочный ISO-образ, содержащий базовую ОС, драйверы для различных устройств и набор утилит MIND, используемый приёмником для загрузки во временную ОС для миграции или репликации.

Описание процесса миграции

Для выполнения миграции требуется сетевое взаимодействие между компонентами: агент на источнике и приёмнике устанавливает соединение с контроллером для управления процессом и обмена служебными данными, а основной поток данных передаётся напрямую между источником и приёмником. Параметры сетевого канала (в том числе MTU) влияют на стабильность соединения и скорость переноса данных.

Требования к конфигурации источника и приёмника

Поддерживаемые конфигурации

Подробная информация о поддерживаемых операционных системах, гипервизорах, платформах виртуализации и облачных платформах в MIND Migrate #guest приведена в документе «Матрица совместимости MIND Suite».

Разметка дисков

MIND Migrate #guest поддерживает работу с дисками, использующими схемы разметки MBR (Master Boot Record) и GPT (GUID Partition Table) для источников на базе Windows и Linux.

Файловые системы и шифрование

Windows

Для источников на Windows поддерживаются файловые системы NTFS и FAT32 (поддерживается в офлайн-режиме; запись на диск не выполняется).

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

Linux

Для источников на Linux поддерживаются основные файловые системы, включая vfat, ext2, ext3, ext4, xfs, jfs, btrfs.

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

Журнальные диски

Windows

При миграции Windows с использованием журнального диска источника требуется диск, размеченный под GPT (для UEFI-систем) или под MBR (для BIOS-систем) и отформатированный в NTFS.

Менеджеры томов и RAID

Windows

MIND Migrate #guest поддерживает обычные (Basic) диски в Windows и не поддерживает динамические (Dynamic) диски.

Linux

При работе с источниками на Linux MIND Migrate #guest поддерживает:

сырые диски с использованием разделов;
сырые диски без использования разделов;
диски, управляемые LVM (Logical Volume Manager).

Не поддерживаются:

MDRaid: MIND Migrate #guest не поддерживает миграцию данных с дисков, объединённых в MDRaid-массивы. Если в системе используются такие диски, предварительно разберите MDRaid-массив и затем используйте MIND Migrate #guest для миграции данных с каждого отдельного диска.
LVM с Thin-lvol: MIND Migrate #guest не поддерживает миграцию данных с логических томов LVM, которые используют технологию Thin-lvol.

Важно

Если в мигрируемой системе обнаружены неразмеченные блочные устройства, MIND Migrate #guest отображает предупреждение: «В мигрируемой системе обнаружены неразмеченные блочные устройства, они будут перенесены без изменений». Данные с неразмеченных блочных устройств копируются только один раз на этапе первоначальной синхронизации.

Дополнительное ПО и драйверы

В большинстве случаев источник и приёмник не требуют установки дополнительного ПО. Предварительное требование — наличие утилиты командной строки curl (client URL). Обычно она предустановлена, но может отсутствовать в некоторых дистрибутивах (например, Debian).

Остальные компоненты контроллер доставляет на эти машины автоматически.

Драйверы

Драйвер поставляется как набор исполняемых файлов и библиотек. Пакетная установка не выполняется: утилиты заранее собраны под конкретное ядро ОС.

Драйвер должен быть заранее загружен на контроллер. Если требуемого драйвера нет, платформа показывает предупреждающее сообщение на этапе валидации миграционного задания.

Примечание

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

Общий план миграции

Подготовка приёмника: использование образов KTMU в режиме «boot to RAM».
Переразбивка дисковой структуры: выполняется в зависимости от BIOS/UEFI.
Организация сетевого канала между машинами.
Миграция: перенос данных выполняется по сценарию для Linux или Windows, с использованием MIND Flow или без него.
Выгрузка драйверов MIND.
Оптимизация перенесённой машины под целевую платформу:
- применение настроек файловых систем;
- применение сетевых настроек;
- активация драйверов целевой платформы.
Выключение или перезагрузка машин (в зависимости от настроек миграционного задания).
После завершения миграции приёмник стартует с настройками исходной системы.

Подготовка приёмника и временная ОС

Миграция источника предполагает наличие приёмника (целевой ВМ или физической машины) в соответствии с требованиями ОС и параметрами источника.

Способ создания приёмника зависит от доступности целевой платформы для контроллера:

Ручной — приёмник создаётся и настраивается пользователем. Сценарий применяется, например, в закрытом контуре или при отсутствии возможности подключения контроллера к целевой платформе виртуализации.
Автоматический — приёмник создаётся на основе данных, собранных с источника, с использованием механизмов автоматизации, которые взаимодействуют с программными интерфейсами целевой платформы. Для этого на платформе заранее должен быть добавлен и сконфигурирован шаблон ОС (Linux/Windows). Подготовка ОС для шаблона не отличается от подготовки ОС при ручном создании приёмника, а способ добавления шаблона на платформу описан в документе «Руководство администратора MIND Migrate #guest».

Временная ОС приёмника выбирается по семейству ОС источника:

для миграции Linux используется временная ОС приёмника на базе Linux;
для миграции Windows используется временная ОС приёмника на базе Windows.

Важно

Для выполнения миграции Secure Boot на источнике и приёмнике должен быть отключён.

RAM-диск

При миграции MIND Migrate #guest может использовать RAM-диск: в этом режиме временная ОС приёмника загружается в оперативную память приёмника, а затем выполняется копирование операционной системы источника. После копирования приёмник перезагружается и запускается с использованием перенесённой ОС.

Требования к оперативной памяти

Для размещения RAM-диска приёмник должен иметь объём оперативной памяти:

Windows — 1,5 ГБ и более;
Linux — 1 ГБ и более.

Поддерживаемые ОС и образы временной ОС приёмника

Для настройки временной ОС приёмника используйте следующие операционные системы:

Windows — Windows Server 2016, Windows Server Core 2016 или Windows 10;
Linux — Astra Linux 1.7.7, RED OS 8.0.4, RHEL 8.0, SberLinux 8.10.x или Ubuntu 20.04.

В качестве временной ОС приёмника используются образы, заранее подготовленные компанией MIND и загружаемые в оперативную память:

Windows — Windows Kernel Tools with MIND Utilities (wktmu.wim и wktmu.sdi);
Linux — Linux Kernel Tools with MIND Utilities (lktmu.iso).

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

Изменение разметки и конфигурации разделов

Поддерживаемые изменения дисковой структуры

В ходе миграции структура целевого диска восстанавливается на основе конфигурации источника с использованием штатных системных утилит. Применяемая схема разметки дисков приёмника зависит от двух факторов источника:

типа ОС (Linux/Windows);
типа микропрограммного кода (BIOS/UEFI).

Для Linux дополнительно поддерживается миграция машин с сырыми дисками (без форматирования и файловой системы), с дисками с разделами, а также с дисками под управлением LVM.

Разделы swap не копируются и создаются на приёмнике в идентичной конфигурации.

Ниже приведены поддерживаемые комбинации и поведение MIND Migrate #guest в каждом случае.

Windows

В Windows схема разметки загрузочного диска зависит от типа микрокода: для BIOS используется MBR, для UEFI — GPT.

Важно

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

Миграция из BIOS в BIOS не требует модификации дисковой структуры. На приёмнике используется MBR.

Миграция из UEFI в UEFI не требует модификации дисковой структуры. На приёмнике используется GPT.

Миграция из UEFI в BIOS приводит к преобразованию структуры из GPT в MBR. В ходе выполнения миграционного задания на целевом диске приёмника создаётся новый раздел размером 500 МБ в NTFS для размещения загрузчика (boot) и утилит восстановления системы (Windows Recovery). Разделы EFI System Partition и MSR (Microsoft Reserved) не переносятся.

Миграция из BIOS в UEFI приводит к преобразованию структуры из MBR в GPT. Если на источнике присутствовали разделы boot или Windows Recovery, они не переносятся.

Важно

При миграции BIOS → UEFI или UEFI → BIOS последовательность размещения разделов может измениться.

Linux

В Linux при микрокоде BIOS разметка загрузочного диска может быть как MBR, так и GPT; при микрокоде UEFI используется GPT.

Миграция из BIOS MBR в BIOS не требует модификации дисковой структуры. На приёмнике используется разметка источника.

Тип таблицы разделов:

источник использует MBR;
приёмник использует MBR.

Миграция из BIOS GPT в BIOS не требует модификации дисковой структуры. На приёмнике используется GPT.

Тип таблицы разделов:

Источник использует GPT;
Приёмник использует GPT.

Миграция из UEFI в UEFI не требует модификации дисковой структуры. На приёмнике используется GPT.

Тип таблицы разделов:

Источник использует GPT;
Приёмник использует GPT.

Миграция из UEFI в BIOS сохраняет структуру GPT, однако для загрузчика BIOS требуется создание дополнительного раздела.

Тип таблицы разделов:

Источник использует GPT;
Приёмник использует GPT.

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

bios_grub;
boot (если был на источнике);
boot/efi.

Миграция из BIOS MBR в UEFI приводит к преобразованию структуры из MBR в GPT. В ходе выполнения миграционного задания на целевом диске создаётся новый раздел размером 500 МБ для размещения раздела boot/efi. После этого с источника переносятся остальные разделы с данными.

В связи с этим размер диска приёмника должен превышать размер диска источника как минимум на 500 МБ.

Важно

Не поддерживается миграция Linux-машин из режима BIOS в UEFI, если на источнике отключена поддержка файловой системы vfat. В этом случае невозможно создать загрузочный раздел EFI.

Тип таблицы разделов:

Источник использует MBR;
Приёмник использует GPT.

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

boot/efi;
boot.

Миграция из BIOS GPT в UEFI не требует модификации дисковой структуры. На приёмнике используется GPT.

Тип таблицы разделов:

Источник использует GPT;
Приёмник использует GPT.

Целевые дисковые устройства

Целевой диск с ОС (Windows и Linux)

Целевой диск, на котором размещается операционная система, должен быть не меньше диска с ОС источника. Например, если ОС источника установлена на диске объёмом 100 ГБ, размер целевого диска с ОС должен быть не менее 100 ГБ.

Примечание

При миграции между режимами UEFI и BIOS может потребоваться увеличение диска на приёмнике (обычно от нескольких МБ до 1 ГБ).

Для Windows: миграция UEFI > BIOS

При миграции из режима UEFI в режим BIOS, если на загрузочном диске используется четыре или более разделов, размер целевого загрузочного диска должен быть на 1 ГБ больше исходного. Например, если на источнике размер загрузочного диска — 80 ГБ, на приёмнике требуется загрузочный диск объёмом 81 ГБ.

Важно

Миграция машин с разными типами дисков (например, IDE + SCSI) не поддерживается. Для всех дисков системы должен использоваться один тип дискового контроллера.

Диски данных (если применимо)

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

Перенос данных

MIND Migrate #guest поддерживает два метода переноса данных: миграцию с остановкой работы приложений (без использования MIND Flow) и безостановочную миграцию (с использованием MIND Flow).

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

При использовании MIND Flow после первичной (полной) синхронизации запускается инкрементальная синхронизация с применением механизма отслеживания изменённых блоков (CBT — Change Block Tracking). Данные реплицируются поблочно: передаются только изменившиеся блоки между двумя последовательными снапшотами.

В описании этапов используются обозначения консистентно и неконсистентно.

Консистентно – состояние данных на приёмнике пригодно для запуска приложений.

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

Linux без MIND Flow

Перенос данных выполняется в режиме клонирования: состояние источника фиксируется на момент первичного создания клона. Для консистентного состояния приложения на период миграции требуется остановка приложения до запуска миграционного задания.

Инициализация (неконсистентно):
- создание консистентного снапшота файловой системы исходных блочных устройств с использованием технологии MIND Block Device;
- создание CBT-журнала;
- создание COW-журнала (Copy-on-write).
Копирование данных (неконсистентно) на приёмник поочерёдно с каждого исходного устройства.
Финальный разрыв (консистентно):
- завершение работы со снапшотом и его удаление;
- выгрузка драйвера MIND (если он использовался на источнике).

Linux с MIND Flow

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

Инициализация (неконсистентно):
- создание консистентного снапшота файловой системы исходного блочного устройства с использованием технологии MIND Block Device;
- создание CBT-журнала;
- создание первого COW-журнала (Copy-on-write).
Копирование данных (неконсистентно) на приёмник:
- используется оригинальный диск источника;
- фиксируется первый COW-журнал.
Ведение CBT-журнала (консистентно):
- фиксируется второй COW-журнал;
- удаляется первый COW-журнал.
Ведение COW-журнала (неконсистентно):
- создаётся третий COW-журнал;
- выполняется обновление целевого диска с использованием второго COW-журнала и CBT-журнала.
Ведение CBT-журнала (консистентно):
- фиксируется третий COW-журнал;
- удаляется второй COW-журнал.
Этапы № 4 и № 5 могут повторяться до момента принятия решения о финальном разрыве. После завершающего обновления целевого диска достигается консистентное состояние данных, что является критерием успешного завершения миграционного задания по сценарию MIND Flow.
Финальный разрыв (консистентно):
- завершение работы со снапшотами;
- обновление диска приёмника с использованием последних COW- и CBT-журналов;
- удаление текущего COW-журнала;
- выгрузка драйвера MIND (если он использовался на источнике).

Windows без MIND Flow

Перенос данных выполняется в режиме клонирования: состояние источника фиксируется на момент первичного создания клона. Для консистентного состояния приложения на период миграции требуется остановка приложения до запуска миграционного задания.

Инициализация (неконсистентно):
- создание консистентного снапшота файловой системы исходных блочных устройств с использованием технологии Microsoft VSS.
Копирование данных (неконсистентно) на приёмник поочерёдно с каждого исходного устройства.
Финальный разрыв (консистентно):
- завершение работы со снапшотом и его удаление.

Windows с MIND Flow

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

Инициализация (неконсистентно):
- создание консистентного снапшота файловой системы исходных блочных устройств с использованием технологии Microsoft VSS;
- создание CBT-журнала на уровне NTFS.
Копирование данных (неконсистентно) на приёмник:
- используется оригинальный диск источника.
Обновление данных (консистентно):
- создание второго VSS-снимка;
- обновление целевого диска с использованием второго VSS-снимка и CBT-журнала.
Этот этап синхронизации может повторяться до момента принятия решения о финальном разрыве.
Финальный разрыв (консистентно):
- завершение работы со снапшотами;
- обновление диска приёмника с использованием последних VSS-снимков и CBT-журналов;
- выгрузка драйвера MIND (если он использовался на источнике).

После завершающего обновления целевого диска достигается консистентное состояние данных, что является критерием успешного завершения миграционного задания по сценарию MIND Flow.

Обработка сбоев

При отключении и последующем включении источника или приёмника перезапустите миграцию вручную.
При потере сетевого соединения между приёмником и источником задание автоматически пытается восстановить соединение и возобновить миграцию.
Если соединение не удаётся восстановить в течение установленного тайм-аута, задание переходит в статус Ошибка.
После перехода задания в статус Ошибка миграция считается прерванной. Для продолжения работы перезапустите миграцию вручную.
При прерывании задания на миграцию или его завершении с ошибкой агент на источнике удаляется автоматически.

Интерфейс MIND Migrate #guest

Настройка прав доступа

Возможности Пользователя задаются Администратором контроллера и определяются заданной ролью. Подробная информация об управлении ролевой моделью в MIND Migrate #guest приведена в документе «Руководство администратора MIND Migrate #guest».

Аутентификация

Для начала работы с платформой MIND Migrate #guest откройте страницу веб-интерфейса контроллера в браузере, используя IP-адрес, который был задан при установке программного комплекса и перейдите на вкладку MIND Migrate. При аутентификации на странице потребуется ввести логин и пароль, которые можно получить у вашего Администратора MIND Migrate #guest.

Важно

Для защиты паролей пользователей в MIND Migrate #guest применяются следующие меры:

Данные пользователей хранятся в базе данных.
Пароли пользователей хэшируются с использованием алгоритма bcrypt.
Администратор MIND Migrate #guest может управлять парольными политиками.

Основные элементы интерфейса

Интерфейс MIND Migrate #guest имеет следующий вид:

В состав интерфейса контроллера входят:

Меню навигации — содержит список разделов, доступных Пользователю; позволяет быстро перемещаться между функциональными областями контроллера.
Рабочая область — занимает основную часть интерфейса, расположенную справа от меню навигации; здесь отображается содержимое выбранного раздела: управляющие элементы и данные.
Панель управления Пользователя:
- Иконка Сбор диагностической информации для дополнительного анализа и отладки со стороны разработчиков (отображается при наличии некритичной ошибки).
- Иконка открывает список доступных Пользователю тенантов, созданных Администратором.
Важно

В разных тенантах могут быть разные проекты. Если в выбранном тенанте не хватает данных, проверьте, что выбран нужный тенант: нажмите иконку и просмотрите раскрывающийся список.
- Иконка Обновить страницу позволяет обновить данные в необходимом разделе и доступна на любой странице интерфейса.
- Иконка Уведомления показывает количество системных уведомлений.
- Имя пользователя, при нажатии на которое отображаются настройки профиля.

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

После нажатия на иконку открывается список объектов. Для поиска нужного объекта начните вводить его имя в строке поиска.

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

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

Настройки профиля

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

На вкладке Настройки отображаются:

имя Пользователя;
e-mail Пользователя;
информация о лицензии MIND Migrate #guest;
кнопка выбора языка интерфейса (русский/английский);
кнопка выбора темы интерфейса (светлая/тёмная);
кнопка перехода в форму смены пароля;
включение/отключение режима медленных подключений.

Для перехода к форме смены пароля нажмите иконку .

Раздел Проекты

В разделе Проекты отображён список проектов миграции, созданных текущим Пользователем.

Существующие проекты нельзя переназначить или открыть для других Пользователей.

Таблица с проектами содержит следующие столбцы:

Столбец выбора для одного или нескольких проектов.
ID — уникальный идентификатор проекта.
Имя — наименование проекта.
Описание — поле, содержащее дополнительную информацию о проекте.
Дата создания — дата и время создания проекта.
Всего — суммарное количество заданий в данном проекте.
Активные — количество активных заданий в проекте.
Завершённые — количество завершённых заданий в проекте.
Ошибки — количество заданий с ошибками в проекте.
Действия — базовые операции с проектами (редактировать, удалить).

Примечание

В интерфейсе все поля с датой и временем отображаются в локальной временной зоне Пользователя. По умолчанию используется часовой пояс браузера. Изменить его можно в разделе Администрирование > Общие настройки.

По проектам можно посмотреть сводную информацию:

Нажмите + Создать проект и заполните параметры в открывшемся справа окне.

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

На вкладке Группы находятся задания, объединённые в группы для общей оптимизированной настройки параметров.

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

На вкладке Сводная информация можно отслеживать статус заданий конкретного проекта, просматривать аналитику ресурсов и конфигурации машин.

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

Если проигнорировать предупреждение и нажать ОК, то возникает ошибка, уведомляющая о невозможности удалить проект.

Раздел Машины

В разделе Машины отображён список всех машин (источников и приёмников), данные о которых были добавлены на контроллер текущим Пользователем.

Таблица с машинами содержит следующие столбцы:

Столбец выбора одной или нескольких машин.
ID — уникальный идентификатор машины.
Имя — наименование машины.
Проект — проект, в который входит машина.
Агент — указатель подключения агента к машине.
Статус — статус подключённого агента (Создан, ОК, Ошибка).
ОС — операционная система, установленная на машине.
Ядро — ядро ОС, запущенной на машине.
Драйвер — название и версия драйвера MIND, который используется на машине в процессе миграции.
URI — адрес подключения к машине с указанием протокола, IP и порта.
Тип — тип ОС на машине (Linux, Windows).
Ключ — ключ доступа, для выполнения удаленных операций на машине: установка, переустановка, удаление агента.
Описание — описание машины.
Дата создания — дата и время создания машины.
Токен агента — уникальный идентификатор установленного агента.
Прокси группа — прокси-группа, выбранная на машине.
Действия — перечень доступных операций с машинами: инвентаризация, редактировать, удалить, действия с агентом.

Если драйвер установлен на контроллере, его название отображается зелёным цветом. Подробнее о состоянии Отсутствует драйвер см. в разделе Отсутствие драйвера.

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

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

Важно

Регистрировать или отклонять машины из вкладки Незарегистрированные могут пользователи с ролями sysAdmin, superUser и powerUser.

Можно просмотреть статистику по машинам.

Создание машин

Доступны следующие методы создания машин на контроллере:

Одиночное создание

Чтобы добавить одну машину:

Нажмите + Создать машину.
Заполните обязательные поля.
Нажмите Сохранить.

В форме создания новой машины заполните следующие поля:

Имя — название машины для отображения в интерфейсе MIND;
Описание — необязательный комментарий к машине;
Проект — проект, к которому будет привязана новая машина;
Тип операционной системы — Windows или Linux;
IP/FQDN — статический адрес добавляемой машины или её полное доменное имя;
Расширенные настройки:
- Порт SSH/SMB — открытый порт для удалённого подключения к машине. По умолчанию — 22 для SSH (Linux) или 445 для SMB (Windows);
- Порт агента — свободный порт машины, на котором можно будет запустить сервис агента. По умолчанию — 8999;
- Прокси группа — прокси-серверы для передачи трафика;
Ключи доступа — необязательные данные для доступа к добавляемой машине. Требуются только при автоматической установке агента. MIND Migrate #guest поддерживает два типа ключей доступа: локальные и внешние. Ключи с типом Local — локально созданные пользователем ключи. При создании ключей с типом SecMan выполняется интеграция с внешней системой хранения секретов. Подробная информация по работе с ключами доступа приведена в разделе Ключи доступа;
Установить агент автоматически — после нажатия кнопки Сохранить контроллер подключится к машине по SSH/SMB с помощью предоставленных ключей доступа. Для ручной установки агента снимите флажок Установить агент автоматически и нажмите Сохранить. Подробная информация по работе с агентом приведена в разделе Установка агента;
Игнорировать неподдерживаемые конфигурации — позволяет настраивать и запускать задания для источников и приёмников, которые не прошли проверку на совместимость.

Например, при включении параметра Игнорировать неподдерживаемые конфигурации на источнике можно будет мигрировать машины с ОС Linux и ядром 2.6.32 на приёмник с дисками, подключёнными к шине VirtIO.

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

При создании новой машины выберите Проект, укажите Имя и Тип операционной системы, затем задайте IP-адрес или FQDN для подключения к машине. Эти данные используются при автоматической установке агента и при выполнении заданий миграции. Остальные поля являются опциональными.

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

Откроется окно SecMan. Введите логин и пароль для подключения к серверу, а также одноразовый пароль OTP. Учётные данные получите у Администратора системы.

Массовое создание

Чтобы создать сразу несколько машин:

Нажмите + Добавить несколько.
На вкладке Общие выберите проект и тип ОС.
Задайте общую часть наименования, начальный номер для присвоения имён в интерфейсе MIND и количество машин.

Чтобы ввести имена машин списком, в строке Способ ввода выберите параметр Список.

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

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

Нажмите Заполнить. Параметры списка машин актуализируются.

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

Нажмите Заполнить. Список машин актуализируется.

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

Нажмите ОК. Новые машины появятся в общем списке машин:

Создание из файла

Чтобы использовать для добавления подготовленный файл со списком параметров машин, нажмите + Добавить из файла. Откроется форма:

Скачайте шаблон в формате .xlsx для самостоятельного заполнения параметров добавляемых машин.

Укажите необходимую информацию о машинах и загрузите этот файл на контроллер:

projectid — индивидуальный номер проекта, предварительно добавленного в MIND;
name — название машины для отображения в интерфейсе MIND;
os — тип операционной системы: Windows или Linux;
vaultId — индивидуальный номер ключей доступа, предварительно добавленных в MIND;
vault names — название ключа доступа;
ip — статический адрес добавляемой машины;
port — порт удалённого подключения к машине;
agentPort — порт, на котором слушает агент.

Импорт

Чтобы интегрировать объекты инфраструктуры из VMware vSphere для автоматизации, нажмите + Импорт. Откроется форма:

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

В списке машин появится машина со статусом Создано.

Массовое редактирование машин

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

Для этого выберите нужные машины, нажмите на и выберите Редактировать.

Откроется форма редактирования.

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

Раздел Прокси

В данном разделе производится настройка маршрутизации трафика во время миграции. Раздел Прокси подробнее описан в документе «Руководство администратора MIND Migrate #guest».

Раздел Ключи доступа

В разделе Ключи доступа отображается информация о добавленных Пользователем ключах доступа для доступа к машинам. Эти записи можно переиспользовать в нескольких проектах и миграционных заданиях Пользователя, если, например, связка «логин-пароль» не меняется от машины к машине.

Таблица с ключами доступа содержит следующие столбцы:

Столбец выбора одного или нескольких ключей.
Имя — наименование ключа доступа.
ID — уникальный идентификатор ключа доступа.
Количество связей — количество машин, использующих данный ключ доступа.
Машины — наименование машин, использующих данный ключ доступа.
Дата создания — дата создания ключа доступа.
Действия — базовые операции с ключами (редактировать, удалить).

Пользователь может создать новый ключ доступа. MIND Migrate #guest поддерживает два типа ключей: Local и SecMan. Ключи с типом Local — это локально созданные пользователем ключи, которые хранятся непосредственно в базе данных контроллера. При создании ключей с типом SecMan осуществляется интеграция с внешней системой хранения секретов.

Создание ключа Local

Для создания нового ключа с типом Local:

Нажмите + Создать.
В открывшейся форме создания нового ключа доступа заполните поля в зависимости от метода аутентификации на машине:

Имя ключа — название записи для отображения в интерфейсе MIND;

Тип — выбор типа ключа: Local;

Логин — имя учётной записи на машине (макс. длина — 30 символов). Если машина в домене, используйте формат .\<UserName> для локальной записи и <DomainName>\<UserName> для доменной. Если машина в домене с авторизацией по протоколу Kerberos, используйте формат, в котором реалм (REALM) Kerberos указывается после знака @, <UserName>@<RealmName>.

Пароль — пароль учётной записи (макс. длина — 32 символа);

Закрытый ключ SSH — private key в формате OpenSSH;

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

Создание ключа SecMan

Для создания нового ключа с типом SecMan:

Нажмите + Создать.
В открывшейся форме заполните поля:
- Имя ключа — название записи для отображения в интерфейсе MIND;
- Тип — тип ключа: SecMan;
- Сервер — название сервера, который указал Администратор при настройке интеграции;
- Тип ОС — Windows или Linux;
- Параметры подключения — данные для подключения к серверу.
Заполните шаблон в поле Параметры подключения с учётом типа потока.

Параметры для Linux используются, когда указан тип потока linux:
- linCredsPath — путь к репозиторию, который можно получить у Администратора SecMan. Укажите значение в формате linPath;
- flowType — тип потока. Значение по умолчанию — linux.
Для использования SecMan через SSH-ключ только для Linux добавьте следующие параметры:
- flowType — специальный метод взаимодействия с SecMan для входа по имени пользователя и ключу. Значение по умолчанию — signed_key;
- appRolePath — путь к репозиторию, который можно получить у Администратора SecMan. Укажите значение в формате path_approle;
- usr — имя пользователя для входа на ВМ;
- enginePath — путь до SSH-движка, необходимый для подписания ключа;
- role — роль SSH-движка. Роль создаётся внутри SecMan, через неё подписывается публичный ключ и генерируется сертификат, с которым выполняется вход на ВМ.
Параметры для Windows используются, когда указан тип потока Windows.

Метод отличается от типа потока linux тем, что перед получением доступа к KV-движку с логином и паролем необходимо аутентифицироваться по approle.
- appRolePath — путь к репозиторию, который можно получить у Администратора SecMan. Укажите значение в формате path_approle;
- usr — имя пользователя Windows для подключения к удалённому серверу;
- flowType — тип потока. Значение по умолчанию — Windows.
После заполнения полей формы нажмите Сохранить. Созданный ключ отобразится в разделе Ключи доступа.
Для дальнейшего взаимодействия с SecMan пройдите аутентификацию на сервере. Для этого в контекстном меню выберите действие Логин.
Откроется окно авторизации SecMan. Введите логин и пароль подключения к серверу, а также одноразовый пароль OTP. Учётные данные уточните у Администратора системы.

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

Создать несколько записей можно следующим способом:

Загрузите на контроллер заполненный файл, шаблон которого можно скачать после нажатия кнопки + Добавить из файла.

Шаблон имеет формат .xlsx для самостоятельного заполнения параметров доступа.
Укажите необходимую для доступа к машинам информацию и загрузите этот файл на контроллер.
Важно

Для обеспечения безопасности ключей доступа в MIND Migrate #guest применяются следующие меры:
- Данные ключей хранятся в базе данных;
- Пароли ключей шифруются с использованием алгоритма AES.

Чтобы отредактировать ключ доступа, нажмите Редактировать. Откроется форма, где ранее сохранённые логин, пароль, закрытый ключ SSH и парольная фраза не отображаются из соображений безопасности. После редактирования нажмите Сохранить.

Раздел Скрипты

В разделе Скрипты Пользователь может добавить дополнительные индивидуальные наборы команд или инструкции для выполнения на источнике или приёмнике на разных этапах репликации.

Добавление скрипта

Для добавления скрипта выполните следующие действия:

Нажмите + Создать скрипт.
В окне Создать скрипт введите:
- Имя — название скрипта для отображения в интерфейсе MIND;
- Описание — (необязательно) комментарий к скрипту;
- Linux/Windows — в зависимости от операционной системы поддерживаются разные оболочки командной строки: для Linux-систем — Bash, для Windows — PowerShell.
Загрузите файл, содержащий программный код скрипта.
Нажмите Сохранить.

Скрипт отобразится на вкладке Скрипты. Можно скопировать ID скрипта, нажав иконку , или отредактировать его, нажав .

Добавление и настройка сценариев

После добавления первого пользовательского скрипта в этом разделе появится вкладка Сценарии, где можно задать последовательность исполнения скриптов на ключевых этапах миграции.

Для добавления сценария:

Нажмите + Создать сценарий.
Укажите имя сценария.
Выберите, где должны исполняться скрипты – на источнике или на приёмнике.
Нажмите + Добавить скрипт.
Выберите этап запуска скрипта – Начало, Снимки, Завершение для источника и Завершение для приёмника.
Выберите Условия запуска скрипта:
- Для вкладки Начало (когда синхронизация началась) на источнике:
  - Перед первым снимком
  - После первого снимка
  - После первичной синхронизации
- Для вкладки Снимки (когда выполняется режим Flow-синхронизации) на источнике:
  - Перед каждым снимком
  - После каждого снимка
  - Перед последним снимком
  - После последнего снимка
- Для вкладки Завершение (когда синхронизация завершилась) на источнике:
  - После финальной синхронизации
- Для вкладки Завершение на приёмнике:
  - Перед перезагрузкой приёмника
Скрипт — выберите один из ранее созданных пользовательских скриптов.
Что делать в случае ошибки — выберите действие при возникновении ошибки:
- Продолжить миграции – миграция продолжается без остановки;
- Остановить миграции с ошибкой – миграция останавливается с сообщением об ошибке в скрипте;
- Запустить запасной скрипт – запускается резервный скрипт на случай возникновения ошибок в основном. Для выбора запасного скрипта откроется дополнительное поле выбора.
Повторите добавление, если требуется несколько скриптов на одном этапе.
При необходимости нажмите для удаления скрипта.
Нажмите Сохранить.

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

Примечание

На этапе проверки приёмника скрипты всегда выполняются от имени пользователя root, поэтому использование sudo в скриптах не требуется. На источнике и приёмнике скрипты выполняет mind_agent на всех этапах.

Важно

При использовании пользовательских скриптов для корректного завершения миграции необходимо, чтобы скрипт завершался с каким-либо кодом возврата. Не поддерживается выполнение «бесконечных» скриптов. В противном случае процесс миграции остановится и не перейдёт к следующему этапу.

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

Номер шага	Где запускается скрипт	Когда запускается	Миграция машины с Flow	Миграция машины без Flow
1	Источник	Перед первым снимком	+	+
2	Источник	После первого снимка	+	+
5	Источник	Перед каждым снимком	+	-
6	Источник	После каждого снимка	+	-
7	Источник	После первичной синхронизации	+	+
8	Источник	Перед последним снимком	+	-
9	Источник	После последнего снимка	+	-
10	Источник	После финальной синхронизации	+	+
1	Приёмник	Перед перезагрузкой приёмника	+	+

Примечания:

+ – скрипт будет выполняться на данном шаге для данного типа задания;

- – скрипт не будет выполняться на данном шаге для данного типа задания.

Раздел Администрирование

Подробности работы с разделом Администрирование см. в документе «Руководство администратора MIND Migrate #guest».

Раздел API

В разделе API находится интерфейс интегрированного в платформу MIND Migrate #guest фреймворка Swagger, связанного со спецификацией OpenAPI.

Swagger — средство разработки, документирования и тестирования, которое предоставляет возможность знакомства с описанием эндпоинтов, параметров запросов, форматов данных и других важных аспектов доступных API.

Подробное описание возможностей взаимодействия с программными интерфейсами MIND Migrate #guest изложено в документе «Руководство по работе с API».

Раздел Уведомления

Чтобы быстро просмотреть уведомления, нажмите иконку в правом верхнем углу экрана. В открывшейся форме можно просмотреть и скрыть уведомления. Кнопка доступна из каждого раздела интерфейса MIND Migrate #guest.

Для детального просмотра уведомлений выберите в панели навигации раздел Уведомления. Здесь можно выполнить следующие действия:

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

Раздел Документация

В разделе Документация находится документация по продукту MIND Migrate #guest, которая теперь включена в установочный пакет контроллера. Это решение было реализовано для удобства пользователей, развёртывающих сервис через облачных провайдеров и не имеющих доступа к Личному кабинету MIND. Теперь они могут сразу изучить документацию и начать использование продукта.

Раздел Автоматизация

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

На вкладке Платформы можно создать новую платформу — коннектор для облачной инфраструктуры. Она будет содержать в себе сведения о подключении к конкретному типу инфраструктуры.

Чтобы добавить платформу, нажмите + Добавить платформу. Справа откроется окно с параметрами для заполнения.

На вкладке Размещения можно задать контекст, с помощью которого можно оптимизировать создание приёмников на платформе. Создание размещения помогает в упорядочивании мигрированных машин и позволяет поместить их в определённую папку или ресурс.

Раздел Файлы

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

В разделе доступны три вкладки, которые отображают следующие типы файлов:

Драйверы MIND – набор низкоуровневых утилит, используемых в заданиях миграции.
Драйверы устройств – драйверы, которые используются ОС Windows для взаимодействия с физическими или виртуальными устройствами: контроллерами дисков, сетевыми адаптерами и др. При запуске задания контроллер определяет, какие драйверы устройств потребуются на приёмнике после загрузки целевой операционной системы (например, для KVM, VMware vSphere, XEN, Hyper-V и других платформ). Во время процедуры переключения KTMU автоматически добавит эти драйверы в целевую ОС.
Образы KTMU (Kernel Tools with MIND Utilities) – загрузочный образ, содержащий базовую ОС, драйверы для различных устройств и набор утилит MIND, используемый приёмником для загрузки во временную ОС для миграции или репликации.

По умолчанию после установки контроллер уже содержит актуальные версии образов KTMU и драйверы устройств под основные версии ОС Windows для работы на различных типах гипервизоров.

При необходимости администратор может добавить новые версии драйверов или образов на контроллер, загрузив их из Личного Кабинета Пользователя или запросив у Службы Технической поддержки MIND, если нужная версия недоступна для загрузки.

Драйверы MIND, драйверы устройств и образы KTMU могут распространяться в виде одиночных архивов. Каждый архив содержит файл meta.yml с описанием назначения архива и файлы драйверов или образа KTMU. Для ускорения загрузки на контроллер несколько таких архивов могут быть собраны в один пакет (bundle).

Для загрузки нового драйвера или образа KTMU на контроллер:

В разделе Файлы нажмите кнопку + Загрузить файл.
Выберите нужный файл в появившейся форме справа и нажмите кнопку Загрузить.

Для массовой загрузки драйверов или образов KTMU на контроллер:

В разделе Файлы нажмите кнопку + Загрузить пакет.
Выберите нужный zip-архив в появившейся форме справа и нажмите кнопку Загрузить. После загрузки новых драйверов или образов для обновления отображения списка драйверов нажмите кнопку Перечитать файлы.

В качестве альтернативного варианта для добавления драйверов MIND на контроллер можно использовать самораспаковывающийся скрипт mind_drivers_<версия>.sh.

Инструкция по запуску скрипта приведена в документе «Руководство по установке и первичной настройке MIND Suite».

Драйверы для MIND Suite можно скачать из Личного кабинета My.MIND. Инструкция по скачиванию драйверов приведена в документе «Руководство по Личному кабинету My.MIND» в разделе FAQ.

Инструкции по настройке и выполнению миграции

Миграцию можно выполнить двумя способами:

Миграция с ручным созданием приёмника;
Миграция с автоматическим созданием приёмника.

Для проведения миграции:

Проверьте исходное состояние:
- Источник запущен и доступен по сети, приёмник создан;
- На источнике и приёмнике настроены доступы.
Создайте в интерфейсе MIND Migrate #guest новый проект, в рамках которого будут группироваться миграционные задания.
Создайте миграционное задание и добавьте информацию об источнике и приёмнике.
Установите агента.
Запустите автоматическое распознавание характеристик источника и приёмника.
Настройте основные параметры миграции.
Запустите миграцию.
Завершите миграцию и выполните переключение.

Подготовка к миграции

Подготовка источника и приёмника

Перед проведением миграции настройте доступы на источнике и приёмнике:

Отключите Secure Boot на источнике и приёмнике.

Откройте порты, указанные в таблице.

Назначение подключения	Источник трафика	Назначение трафика	Протокол/порт	Требование
Взаимодействие агента с контроллером	Источник, приёмник	Контроллер	TCP 443	Исходящий (по умолчанию)
Передача данных	Источник	Приёмник	TCP 9000	Исходящий (по умолчанию)
Приём данных	Источник	Приёмник	TCP 9000	Входящий (по умолчанию) на приёмнике
Локальное взаимодействие компонентов агента	`localhost`	`localhost`	TCP 8999	Доступен на `localhost`

Настройте одинаковое значение MTU на источнике и приёмнике, а также на всех точках прохождения трафика (физические и виртуальные коммутаторы). Например, 1500 Б.

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

Для автоматической установки агента обеспечьте следующее:

Контроллер имеет доступ к источнику и приёмнику по сети, как указано в таблице.

Назначение подключения	Источник трафика	Назначение трафика	Протокол/порт	Требование
Доступ к машинам с ОС Linux по SSH	Контроллер	Источник, приёмник	TCP 22	Доступен (по умолчанию)
Доступ к машинам с ОС Windows по SMB	Контроллер	Источник, приёмник	TCP 445	Доступен (по умолчанию)

Укажите порт и ключи доступа при добавлении машины на контроллере.

Требования для машин с ОС Windows

Добавьте пользователя, выполняющего установку, в группу Локальные администраторы.
Если для аутентификации на источнике и приёмнике используются локальные учётные записи пользователя, выполните команду на обеих машинах — приёмнике и источнике:
```
New-ItemProperty `
  -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' `
  -Name 'LocalAccountTokenFilterPolicy' `
  -Value 1 `
  -PropertyType DWord `
  -Force
```

Требования для машин с ОС Linux

Убедитесь, что:

Служба SSH установлена и запущена.
На источнике и приёмнике есть пользователь, который может выполнять команды с помощью sudo.

Подготовка машин на ОС Linux

Настройка SELinux

Отключите SELinux на машинах. Для временного отключения выполните команду:

setenforce 0

Настройка root в режиме read-only

Для поддержки защищённых Linux-систем с корнем в режиме read-only (в файле /etc/sysconfig/readonly-root установлено READONLY=yes), кроме обязательного использования журнального диска, требуется донастройка ОС.

До установки агента:

Создайте файл /etc/rwtab.d/mind со следующим содержимым:
```
dirs /opt/mind
dirs /mind
```
Создайте соответствующие директории:
```
mkdir -p /opt/mind
mkdir -p /mind
```
Выполните перезагрузку.

Примечание

Эти действия нужно отменить после миграции: удалите файл /etc/rwtab.d/mind и выполните перезагрузку.

Подготовка машин на ОС Windows

Настройка доступа

Важно

Все команды выполняйте в PowerShell версии 4.0 и выше, запущенном в административном режиме.

Добавьте исключения в Windows Defender. Команды выполняются на обеих машинах — приёмнике и источнике.
- Исключите папку mind на системном диске:
```
Add-MpPreference -ExclusionPath $(Join-Path -Path $env:SystemDrive -ChildPath mind)
```
- Исключите директории и файл, необходимые для корректной установки агента:
```
Add-MpPreference -ExclusionPath 'C:\Program Files\mind','C:\mind','C:\Windows\winexesvc.exe'
```
Настройте правила Windows Firewall для портов, указанных в разделе Подготовка источника и приёмника.
- Разрешите подключение к порту 9000/TCP на приёмнике:
```
New-NetFirewallRule -DisplayName '_port_for_mind_DATA_SEND' `
    -Direction Inbound -Action Allow -Protocol TCP -LocalPort 9000
```
Разрешите запуск PowerShell-скриптов:
```
Set-ExecutionPolicy Bypass -Scope LocalMachine -Force
```
Примечание

Чтобы установить определённые версии паравиртуализованных драйверов QEMU или XEN на Windows Server 2012 (R2), при необходимости включите режим testsigning:
```
bcdedit.exe /set testsigning yes
```
Для получения драйверов обратитесь к производителю платформы виртуализации.
Откройте доступ по протоколу SMB 2.0 в Windows Firewall (порт по умолчанию 445; конкретный порт и ключи доступа указывайте при добавлении машины на контроллере). Команда выполняется на обеих машинах — приёмнике и источнике:
```
New-NetFirewallRule -DisplayName '_port_for_mind_SMB_445' `
    -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445
```
Обеспечьте доступность административной директории Admin$ для удалённого доступа по сети.

Миграция с ручным созданием приёмника

Создание нового проекта

Создайте в интерфейсе MIND Migrate #guest новый проект, в рамках которого будут группироваться миграционные задания. Для этого в разделе Проекты нажмите кнопку + Создать проект.

В открывшемся окне введите имя и описание проекта (необязательное поле) и нажмите кнопку Сохранить.

Созданный проект появится в списке проектов Пользователя.

Создание миграционного задания

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

Откройте созданный проект и нажмите кнопку + Создать задание.
В открывшемся окне введите имя миграционного задания и укажите, какие машины в него войдут. Выберите из существующих или укажите новые источник и приёмник, затем нажмите кнопку Сохранить. Вы можете выбрать из уже добавленных на контроллер машин (всех или только тех, которые прошли инвентаризацию) или создать новые.

Чтобы создать новые машины, нажмите Новая машина и в открывшемся окне заполните обязательные поля для создания источника и приёмника (см. раздел Машины).

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

Таблица с заданиями содержит следующие столбцы:

Столбец выбора одного или нескольких заданий.
ID — уникальный идентификатор задания.
Имя — название задания.
Статус — статус задания (Создано, Проверено, Мигрировало, Ошибка).
Этап — этап миграции, на котором находится задание.
Состояние — состояние задания.
Прогресс — процент выполнения текущего этапа синхронизации и суммарный объем данных для миграции.
Группа — группа, в которую входит задание.
Машины — машины, входящие в задание на миграцию.
Имя хоста — имя компьютера/хоста, на котором установлен контроллер.
Занято — размер занятого дискового пространства на источнике.
Разделы — суммарный размер разделов, синхронизируемых в процессе миграции.
Диски — суммарный размер всех дисков на источнике.
Последнее обновление — дата и время последнего обновления задания.
Завершение Flow — дата и время завершения процесса миграции в режиме Flow.
Дата запуска — дата и время запуска миграции задания.
Окончание первичной синхронизации — дата и время окончания этапа первичной синхронизации задания.
Дата создания — дата и время создания задания.
Действия — перечень доступных операций с заданиями: конфигурировать, инвентаризация, редактировать, удалить, дополнительные действия с процессом миграции.

Создание группы заданий

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

Для создания группы миграционных заданий выполните следующие действия:

Откройте созданный проект и перейдите на вкладку Группы. Нажмите кнопку + Создать группу.
В открывшейся форме выберите задания, которые необходимо включить в группу, отметив их флажками. При большом количестве заданий можно воспользоваться поиском. Заполните поля формы:
- В поле Имя введите название группы.
- В поле Описание при желании введите краткое описание, назначение, признак добавления или какие-либо другие отличительные черты группы заданий.
- Включите переключатель Flow при необходимости («живая миграция» без остановки источника). Выберите дату и время окончания миграции, а также интервал между досыланиями изменений данных на приёмник в секундах.
Нажмите Сохранить. Созданная группа заданий отобразится на вкладке Группы. Таблица с группами содержит следующие столбцы:
- Столбец выбора одной или нескольких групп.
- ID — уникальный идентификатор группы.
- Имя — название группы.
- Задания — задания, входящие в группу.
- Статус — статус группы (Создано, Настроено, Ошибка).
- Синхронизация — синхронизированы ли задания, входящие в группу.
- Дата создания — дата и время создания группы.
- Действия — базовые операции с группами (настроить задания, редактировать, удалить).

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

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

Установка агента

Следующим шагом в подготовке миграции является установка агента на источник и приёмник. Предусмотрено несколько вариантов выполнения этой процедуры — автоматическая установка во время создания машины, автоматическая (одиночная/массовая) и ручная.

Важно

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

Установка во время создания машины

Если на этапе создания машины был установлен флажок в поле Установить агент автоматически, то после этого у машины отобразится иконка — Агент установлен.

Автоматическая установка

Автоматическая установка требует доступности машины по протоколам SSH/SMB (в зависимости от типа ОС) и данных для авторизации в виде заведённой на контроллер записи в разделе Ключи доступа (выполнение команд на уровне sudo/Локального администратора).

В разделе Машины

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

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

В разделе Проекты

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

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

Ручная установка

Ручная установка подразумевает скачивание файлов агента из веб-интерфейса контроллера, копирование их на источник/приёмник и запуск установщика. В этом случае предоставление данных для входа на машины не требуется.

В разделе Машины

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

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

Отобразится боковая панель Установка агента, в которой будет предложено выполнить 2 варианта установки агента:

Через команду, выполнение которой на источнике и приёмнике также приведёт к установке агента без необходимости предоставления SSH/SMB доступа к машинам:
- Скопируйте команду (curl-запрос);
- Перейдите в командную строку машины;
- Выполните запрос на установку.
Через кнопку:
- Нажмите на кнопку Посетить для загрузки. Выполнится загрузка инсталляционного файла агента;
- Скопируйте файл на машину (источник или приёмник);
- Запустите инсталляционный файл агента.

В разделе Машины также имеется возможность установки агента на машины в конкретном тенанте. Для этого необходимо нажать на или , в зависимости от выбранной ОС .

В открывшейся форме можно выполнить следующие действия:

скопировать команду для установки в поле Скопируйте curl и выполнить её на машине.
при нажатии на кнопку Посетить для загрузки скачивается файл установки агента. Данный файл можно запустить на машине и выполнить установку вручную.

В разделе Проекты

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

В соответствующей машине (источнике или приёмнике) выберите Скачать агент.
Установите агенты одновременно на источник и приёмник, нажав Скачать агенты.

После этого отобразится боковая панель Установка агента, где также будут доступны 2 варианта установки агента — через команду или через кнопку.

Дополнительные действия с агентом

Если на машине уже был установлен агент, то его можно переустановить. Для этого:

Выберите Переустановить агент.
Во всплывающем окне введите FORCE, чтобы выполнить команду удаления агента и нажмите кнопку ОК. Ключ FORCE при переустановке агента позволяет игнорировать отличия в публичном адресе.
В правом верхнем углу окна отобразится уведомление о запуске переустановки. Агент установится автоматически. Для переустановки агента вручную выберите Удалить агент. Во всплывающем окне введите FORCE, чтобы выполнить команду удаления агента.

Если на машине уже был установлен агент, но он потерял связь в процессе миграции, то его можно перезапустить. Для этого:

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

Для сформированного задания также можно выполнить переподключение агентов, если во время миграции агент потерял связь с машинами. Для этого:

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

Действия с агентом также доступны через массовое выполнение для всех машин:

Установка агента с авторегистрацией

С помощью интерфейса контроллера MIND Suite можно инициировать процедуру авторегистрации агента. Эта возможность реализует добавление машины-кандидата в определённый тенант, после чего работу с ней можно осуществлять от лица пользователя. Опция получения ссылки для установки агента доступна только пользователям с ролями sysAdmin и secAdmin.

Для этого необходимо выполнить следующие действия:

Перейдите в раздел Администрирование, затем откройте вкладку Управление доступами | Тенанты.
Скопируйте команду установки для соответствующей ОС (Windows/Linux).
Вставьте скопированную команду в консоль ВМ.

Для ОС Linux отобразится команда вида:
```
curl --insecure -X GET \
    https://1.1.1.1/api/v1/agent/autoregbinary/linux \
    -o ./agent_anonymous_installer
chmod +x ./agent_anonymous_installer
sudo ./agent_anonymous_installer -r https://1.1.1.1 -t XXXXXXXX
```
Для ОС Windows отобразится команда вида:
```
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

$url = "https://1.1.1.1/api/v1/agent/autoregbinary/windows";
$fPath = Join-Path -Path $env:temp -ChildPath 'agent_anonymous_installer.exe';

(New-Object System.Net.WebClient).DownloadFile($url, $fPath);

Start-Process -FilePath $fPath `
    -ArgumentList "-r https://1.1.1.1, "-t XXXXXXXX" -Wait -NoNewWindow -Verbose;
```
, в которых:
- -r — публичный адрес контроллера в формате http(s)://<ip_or_fqdn> для подключения агента;
- -t — ключ регистрации агента, уникальный идентификатор, который присутствует у каждого тенанта, и который используется при установке агента для добавления машины-кандидата в определённый тенант.
Выполните скопированную команду на ВМ.

После этого машина-кандидат отобразится в интерфейсе MIND Suite в разделе Машины, на вкладке Незарегистрированные.

Перечень операций агента, выполняемых на машинах

В процессе работы установленный агент MIND и утилиты хоста взаимодействуют с различными компонентами ОС, включая файловую систему, файлы конфигурации и сервисы. Перечень взаимодействий приведён в документе «Руководство по обеспечению безопасности MIND Suite».

Отсутствие драйвера

Чтобы помочь пользователям понять, что для начала миграции необходимы определённые драйверы, в интерфейсе контроллера MIND Migrate #guest добавлен статус Отсутствует драйвер для машин. Этот статус отображается в таблице после процедуры инвентаризации машины, когда становится известна установленная ОС.

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

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

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

Предупреждение о несовместимом ПО для резервного копирования

При инвентаризации машины с ОС Linux MIND Migrate #guest проверяет наличие агентов и модулей ядра сторонних систем резервного копирования (СРК) — Veeam, Кибер Бэкап, Acronis Cyber Protect, Datto, Axcient. Совместная работа с этим ПО не тестировалась и не поддерживается.

Если на машине обнаружено такое ПО, отображается предупреждающая иконка, при наведении на которую появляется сообщение: «Обнаружен модуль <имя_модуля>. Совместная работа со сторонним ПО для резервного копирования не тестировалась и не поддерживается. На время выполнения задания с использованием агента MIND рекомендуется отключить и не запускать резервное копирование с использованием стороннего ПО».

Предупреждение отображается:

в столбце Статус таблицы машин в разделе Машины;
рядом со статусом источника или приёмника на вкладке Сводка мастера конфигурирования задания;
рядом со статусом задания в списке заданий (раздел Проекты), если хотя бы у одной из его машин обнаружено несовместимое ПО.

Примечание

Проверка выполняется только для машин с ОС Linux. Для машин с ОС Windows поддержка проверки не реализована.

Инвентаризация

Подробное описание инвентаризации машин в разделе Машины и в разделе Проекты описано далее.

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

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

Важно

В MIND Migrate #guest реализована возможность прерывания инвентаризации для миграционных заданий и машин с помощью API. Это позволяет выполнять перезагрузку заданий и машин даже в состоянии инвентаризации, освобождая объекты от статуса busy для дальнейших действий, таких как повторный запуск инвентаризации или удаление.

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

Важно

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

для Linux: не менее 1 ГБ;

для Windows: не менее 1,5 ГБ.

При недостаточном объёме памяти процесс завершится с ошибкой Target does not have enough RAM.

В разделе Машины

В разделе Машины напротив интересующей машины нажмите иконку — Инвентаризация.

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

По окончании процесса инвентаризации машина получит статус ОК.

В разделе Проекты

В разделе Проекты перейдите во вкладку Задания и у интересующего миграционного задания нажмите иконку — Инвентаризация и выполните сбор данных для дальнейшей настройки параметров задания.

Подтвердите запуск инвентаризации в открывшемся окне.

Важно

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

По окончании процесса миграционное задание получит статус Проверено.

Настройка параметров миграции

На этом этапе производится указание параметров миграции:

Настройка дискового соответствия мигрируемых машин;
Настройка сетевой конфигурации;
Настройка режима Flow («живая миграция» без остановки источника);
Настройка расширенных параметров миграции.

Настройка отдельного задания

Напротив миграционного задания со статусом Проверено нажмите — Конфигурировать и запустите мастер конфигурации.

Автоматически настройка переходит на вкладку Диски. При необходимости можно вернуться назад на предыдущую вкладку Сводка и посмотреть общие сведения.
Перейдите на вкладку Диски и задайте желаемое соответствие между устройствами источника и приёмника.

Для проведения миграции на источнике требуется не менее 50 МБ свободного дискового пространства на каждом разделе/точке монтирования. В случае, если на источнике нет возможности освободить дисковое пространство или увеличить разделы, возможно настроить миграцию с использованием журнального диска на источнике.

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

После подтверждения переноса неразмеченного диска миграция продолжается.

Примечание

Для машин с ОС Windows миграция неразмеченных дисков не поддерживается и при попытке выбора таких дисков для переноса/репликации в настройках задания отобразится ошибка.
Если вы хотите использовать дополнительный журнальный диск для учёта изменений источника, в выпадающем списке:
- Выберите Ввести путь и укажите путь к каталогу, где будут размещаться файлы журналов;
- Выберите Выбрать диск и укажите блочное устройство, на котором будут храниться журналы;
- Выберите RAM-диск и укажите объём оперативной памяти, которую требуется зарезервировать для создания журнального RAM-диска.
Размер RAM-диска может быть задан в диапазоне от 20 до 70 % от свободного объёма памяти на источнике.
Для получения информации о свободном объёме диска откройте вкладку Диски в информации о машине:
- В столбце Свободно отображается доступный объём на дисках и разделах с файловой системой.
- В столбце Неразмеченное пространство отображается область диска без файловой системы, а также незанятая разметкой часть диска.
Нажмите Сохранить и перейдите к следующему шагу. В процессе настройки задание будет иметь статус Частично настроено.
На вкладке Сеть можно выполнить настройку сетевых интерфейсов приёмника.

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

Переключатель Переносить и исправлять маршруты в конфигурации сети включает перенос всех существующих маршрутов на приёмник. Для дополнительных маршрутов значение шлюза заменяется на шлюз по умолчанию.
- Настроить resolv.conf — включает настройку файла resolv.conf на приёмнике. Используйте эту опцию, чтобы задать общую DNS-конфигурацию для всей машины, а не для отдельных сетевых интерфейсов. Когда переключатель выключен, resolv.conf переносится на приёмник как есть. Когда переключатель включён, отображается содержимое файла resolv.conf источника, которое можно отредактировать. При переключении на приёмник будет записано указанное содержимое файла resolv.conf. Настройка DNS для отдельных интерфейсов при этом остаётся доступной.
Внимание

Содержимое файла resolv.conf, заданное вручную, не проверяется и не исправляется автоматически.

Некорректная конфигурация может нарушить работу операционной системы на приёмнике.
Чтобы самостоятельно задать интерфейс приёмника:
- Скопируйте настройки сети, используя соответствующие кнопки — или .
- Нажмите Добавить в блоке Интерфейсы приёмника. В открывшемся окне укажите способ конфигурации, тип конфигурации и имя интерфейса или скопируйте настройки из источника или приёмника.
Важно

Выбор способа настройки сети позволяет корректно применять конфигурации адаптеров в зависимости от используемой ОС и её сетевого менеджера (например, netplan или systemd-networkd).

При выборе типа конфигурации Новая конфигурация вы сможете указать конфигурацию самостоятельно в соответствующем поле.

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

При выборе типа конфигурации Статический адрес укажите IP-адрес с диапазоном подсети, сетевой шлюз. Можно также (не обязательно) указать максимальный размер сетевого пакета для передачи (MTU), и адрес DNS-сервера.

Заполните поля вручную или скопируйте данные из конфигурации источника или приёмника нажатием кнопок и соответственно.

Примечание

В случае, если имена сетевых интерфейсов на источнике и приёмнике отличаются, например, ens3 на источнике и enp1s0 на приёмнике, и в настройках задания отключена настройка сети, т. е. переключатель Сеть для указанной пары интерфейсов отключён, то после переключения приёмник запустится с ненастроенным сетевым интерфейсом enp1s0. Для корректного переноса сетевых настроек требуется включить переключатель Сеть и выполнить настройки сетевого интерфейса на приёмнике.
Для редактирования файла hosts на приёмнике в режиме KTMU установите флажок Расширенные настройки.

При установке флажка по умолчанию отображается содержимое файла hosts источника. Вы можете скопировать содержимое файла hosts из источника или приёмника нажатием кнопок и соответственно, или изменить файл самостоятельно. При запуске задания содержимое файла hosts применяется только к приёмнику в режиме KTMU и не применяется к приёмнику после миграции.

Файл /etc/hosts на приёмнике после миграции формируется на основе актуального содержимого файла источника непосредственно при переключении, а не фиксируется на этапе настройки задания. Изменения, внесённые в /etc/hosts на источнике во время миграции, переносятся на приёмник при переключении.

Важно

Если задание на миграцию было запущено на версии 2.15 контроллера, его конфигурация не содержит данных, необходимых для работы этого механизма. Перезапустите такое задание.
После указания сетевых настроек нажмите Сохранить, перейдите на вкладку Синхронизация и задайте параметры режима Flow, если требуется осуществить миграцию без остановки источника:
- Время завершения — целевое время остановки синхронизации источника и приёмника;
- Интервал, в сек — частота, с которой изменения источника будут пересылаться на приёмник.
На вкладке Расширенные настройки выполните настройку расширенных параметров миграции.
В форме Общие настройки укажите, какие действия необходимо выполнить для машин:
- Остановить источник после миграции.
- Остановить приёмник после миграции.
- Установить Паузу перед запуском приёмника (сек).
- Отключить инструмент cloud-init.
- Завершить все процессы перед финальным снимком
  
  Механизм автоматического завершения сервисов в ОС Linux и ОС Windows перед финальным снимком и переключением обеспечивает штатное завершение всех процессов, кроме критически необходимых, чтобы предотвратить запись данных на диск и гарантировать консистентность финального снимка. Этот процесс выполняется с использованием встроенных системных инструментов systemd в Linux и Stop-Process в Windows.
  
  На источнике с ОС Linux при включении опции Завершить все процессы перед финальным снимком агент выполнит остановку всех процессов за исключением процессов сети, SSH и агента MIND перед выполнением финальной синхронизации. Агент пытается штатно завершить активные процессы через systemd, затем, если часть процессов останется в активном состоянии, агент попытается остановить их, отправив сигнал SIGTERM. Если они не будут завершены в течение 15 секунд, завершит их через SIGKILL. Для работы данной функции на ОС Linux требуется, чтобы на источнике была установлена утилита lsof.
- Отключить проверку дисков источника перед миграцией
  
  По умолчанию при запуске задания на источнике выполняется проверка дисков с помощью утилиты chkdsk. Если включить эту опцию, то проверка дисков на источнике будет пропущена, и задание перейдет к следующему этапу.
- Отключить проверку диска перед переключением
  
  Возможность отключения проверки диска перед переключением позволяет ускорить завершение миграции за счёт пропуска данного ресурсоёмкого этапа, что особенно важно при работе с крупными виртуальными машинами в ограниченные технологические окна.
- Удалять закомментированные строки в fstab
  
  В MIND Migrate #guest опция Удалять закомментированные строки в fstab для ОС Linux позволяет настроить поведение миграции содержимого файла /etc/fstab. При включении опции закомментированные строки удаляются. По умолчанию опция отключена, что позволяет сохранить все строки, включая закомментированные, для удобства пользователей, временно отключающих монтирования сетевых файловых систем или неподдерживаемых разделов.
- Скорректировать fstab для приёмника
  
  При включении данной опции записи блочных устройств в fstab для ОС Linux на приёмнике автоматически приводятся в соответствие с используемым драйвером платформы-приёмника.
  
  Файл /etc/fstab на приёмнике формируется на основе актуального содержимого файла источника непосредственно при переключении, а не фиксируется на этапе настройки задания. Изменения /etc/fstab на источнике во время миграции, включая добавление точек монтирования сетевых файловых систем NFS или SMB, переносятся на приёмник при переключении. Опции Удалять закомментированные строки в fstab и Скорректировать fstab для приёмника применяются к этому же обновлённому содержимому.
- Настроить механизм работы с загрузчиком Grub для ОС Linux. В задании на миграцию можно выбрать одну из двух опций:
  - Автовыбор;
  - С источника.
В форме Общие настройки для ОС Windows пользователь может выбрать пакет драйверов, которые будут установлены на приёмнике на этапе переключения (checkout). По умолчанию автоматически выбирается подходящий пакет драйверов, соответствующий версии ОС и целевой платформе виртуализации, на которой запускается приёмник. При необходимости пользователь может подготовить и загрузить на контроллер дополнительный пакет драйверов и выбрать его для установки на приёмнике при настройке задания.
Установите дату и время начала миграции при необходимости.
В форме Передача данных укажите тонкие настройки миграции:
- Шифрование — использовать шифрование при передаче данных между источником и приёмником на ОС Linux и ОС Windows.
  
  Примечание
  
  Возможность отслеживать включение шифрования в задании реализована через передачу соответствующей информации в syslog.
- Компрессия — применить компрессию при передаче данных между источником и приёмником на ОС Linux и ОС Windows.
- Тонкое выделение ресурсов — определяет, как данные записываются на диски приёмника при передаче:
  - Отключено (значение по умолчанию) — передаются все блоки исходного диска, включая пустые области, для которых также выполняется зануление. Такой режим обеспечивает более высокую скорость передачи данных, но может увеличить фактически занятое место на диске приёмника.
  - Включено — на приёмник передаются и записываются только блоки, содержащие данные; пустые блоки не выделяются. Целевой диск сохраняет тонкое выделение ресурсов и занимает меньше места в хранилище, однако скорость передачи данных снижается.
- Режим агрегированной передачи нулей — экспериментальный режим передачи данных с агрегированием нулевых блоков. Функция доступна в режиме предварительной оценки; по умолчанию отключена.
- Порт передачи данных при подключении к приёмнику — указать порт, который будет использоваться для передачи данных.
- Ограничение скорости передачи данных — укажите максимальную скорость передачи данных в диапазоне от 512 Кбит/с до 100 Гбит/с.
- Количество потоков при копировании — задать количество потоков, используемых для копирования данных (автоматически, максимальное количество потоков, указанное количество потоков).
Далее можно завершить настройку по кнопке Завершить или перейти на вкладку Скрипты.
На вкладке Скрипты можно выбрать и применить пользовательские сценарии для дополнительной автоматизации или создать свои. Для отображения полей настроек переведите в активный режим переключатель Активированы.
Завершите конфигурацию настроек, нажав кнопку Сохранить. Откроется страница миграционного задания со статусом Настроено.
В задании со статусом Настроено доступны кнопки:
- Инвентаризация — при нажатии выполняется получение информации о машине для дополнительной настройки и перехода к запуску миграционного задания;
- Протестировать задание — при нажатии воспроизводится тестовый запуск задания на миграцию, без перезагрузки приёмника в KTMU и передачи данных на приёмник. Выполнение данной функции также будет доступно через меню задания в разделе Проекты;
- Конфигурировать — при нажатии можно поменять параметры миграции.
Кнопка Изменить Flow доступна только если в разделе Синхронизация установлены настройки режима Flow. При нажатии на эту кнопку можно изменить настройки синхронизации.

Важно

Если задание на миграцию находится в группе, то редактирование режима Flow в разделе Синхронизация конфигурирования недоступно.
Для редактирования режима Flow в таком задании перейдите во вкладку Группы в проекте и у требуемой группы нажмите , а затем выберите Редактировать. В открывшемся окне установите флажок напротив задания, активируйте режим Flow и нажмите Сохранить.

После всех настроек можно переходить к выполнению миграции.

Настройка группы заданий

В рамках группы заданий также можно выполнить массовое конфигурирование.

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

Чтобы задать интерфейс приёмника:
1. Выберите Включить все и Переносить и исправлять маршруты в конфигурации сети, чтобы включить единые настройки для всех заданий.
2. Переключатель Переносить и исправлять маршруты в конфигурации сети включает перенос всех существующих маршрутов на приёмник. Для дополнительных маршрутов значение шлюза заменяется на шлюз по умолчанию.
3. Переключатель Настроить resolv.conf включает настройку файла resolv.conf на приёмнике для явного задания DNS-конфигурации восстановленной машины.
4. Скопируйте настройки сети, используя иконки или .
5. Выберите Настроить по DHCP, чтобы скопировать соответствующие настройки.
Примечание

Если имена сетевых интерфейсов на источнике и приёмнике отличаются, например, ens3 на источнике и enp1s0 на приёмнике, и в настройках задания отключена настройка сети, т. е. переключатель Сеть для указанной пары интерфейсов отключён, то после переключения приёмник запустится с ненастроенным сетевым интерфейсом enp1s0.

Для корректного переноса сетевых настроек требуется включить переключатель Сеть и выполнить настройки сетевого интерфейса на приёмнике.
На вкладке Передача данных задайте настройки сетевого взаимодействия для пар миграции. При нажатии на кнопку Заполнить все указанные значения подставятся ко всем миграционным заданиям.
В форме Общие настройки:
- Ограничение скорости — укажите максимальную скорость передачи данных в диапазоне от 512 Кбит/с до 100 Гбит/с;
- Порт передачи данных при подключении к приёмнику — по умолчанию указан порт 9000;
- Шифрование — использовать шифрование при передаче данных между источником и приёмником на ОС Linux и ОС Windows;
  
  Важно
  
  Возможность отслеживать включение шифрования в задании реализована через передачу соответствующей информации в syslog.
- Компрессия — применить компрессию при передаче данных между источником и приёмником на ОС Linux и ОС Windows;
- Количество потоков при копировании — задать количество потоков, используемых для копирования данных.
На вкладке Синхронизация можно задать единые параметры режима Flow, если на этапе создания группы данный режим был активирован. Если требуется изменить время завершения синхронизации во всех заданиях, обновите данные в строках Время завершения (целевое время остановки синхронизации источника и приёмника) и Интервал, в сек (частота, с которой изменения источника будут пересылаться на приёмник) и нажмите кнопку Заполнить все. Так указанные параметры безостановочной миграции применятся ко всем заданиям группы.
На вкладке Общие укажите для каждого задания, какие действия запустить до и после миграции:
- Остановить источник после миграции.
- Остановить приёмник после миграции.
- Отключить инструмент cloud-init.
- Завершить все процессы перед финальным снимком.
- Отключить технологический интерфейс после завершения миграции —отключение технологической сети возможно только при использовании автоматического создания приёмника, если в размещении была указана данная сеть.
- Отключить проверку диска перед переключением.
- Удалять закомментированные строки в fstab.
- Скорректировать fstab для приёмника.
- Задать настройки загрузчика Grub.
- Пауза перед запуском приёмника (сек).
Здесь также можно выбрать, какой пакет драйверов будет использоваться для загрузки KTMU и установки драйверов на приёмнике. Поле для выбора пакета драйверов активно для машин с ОС Windows.
Завершите настройку по кнопке Сохранить.
Опционально. Для создания или выбора пользовательских сценариев для дополнительной автоматизации нажмите Перейти к скриптам. Для активации будут доступны скрипты, ранее созданные в разделе Скрипты веб-интерфейса.
Опционально. Настройте параметры отложенной миграции, чтобы все задания в группе были запущены в одно время. Для этого на предыдущем этапе нажмите кнопку Перейти к отложенной миграции или после настройки скриптов нажмите кнопку Пропустить, и настройка автоматически перейдёт на следующий раздел — Отложенная миграция. Выберите Включено, укажите желаемое время начала процесса миграции и нажмите кнопку Заполнить все. Параметр будет применён ко всем заданиям группы.
Завершите конфигурацию настроек, нажав кнопку Сохранить. Откроется страница со списком миграционных заданий в проекте со статусом Настроено.
Перейдите во вкладку Группы — группа, для которой было выполнено конфигурирование, будет иметь статус Настроено.

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

Запуск миграции

Для запуска миграции:

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

Проект отобразится со статусом Миграция отложена.
Чтобы изменить время запуска миграции или отменить запланированную миграцию нажмите Запланировать миграцию.

В процессе миграции в интерфейсе отображается информация по текущему состоянию миграционного задания. При миграции в режиме Flow отображаются объём переданных данных и скорость передачи за итерацию и в среднем.

Процесс миграции состоит из следующих этапов:

Обнаружение машин;
Проверка задания;
Настройка драйверов миграции;
Подготовка приёмника;
Подготовка блочных устройств приёмника;
Синхронизация;
Очистка среды;
Подготовка к первому запуску;
Перезагрузка приёмника.

Примечание

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

Важно

Редактирование данных параметров возможно только до перехода на этап проверки приёмника.

В процессе миграции доступны следующие опции для мигрируемого задания из контекстного меню:

Когда требуется получить временную учётную запись для доступа к машине, загруженной в режиме KTMU, выберите из контекстного меню пункт Временная УЗ. После выбора контроллер отправит API-запрос на соответствующую машину или на приёмник, если действие выполняется для задания.

Если машина не загружена в режиме KTMU, появится предупреждение о недоступности функции.

Если машина загружена в режиме KTMU, откроется окно с логином и временным паролем. Пароль отображается скрытым и может быть показан или скопирован в буфер обмена.

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

Важно

При выключении или включении источника перезапустите миграцию.
Если задание на миграцию было прервано или завершилось с ошибкой, перед повторным запуском установите агент на источник заново.
Если во время активной миграции с Flow или на этапе синхронизации происходит перезагрузка приёмника, миграционное задание завершается с ошибкой. После перезагрузки приёмник не сможет повторно загрузиться в KTMU.
Для продолжения работы заново настройте миграционное задание, используя новый приёмник.
Если пропадает сетевая связь между источником и контроллером, через 60 минут задание перейдёт в статус Ошибка по тайм-ауту, и миграция завершится с ошибкой.

Когда миграция завершена, список доступных опций меняется:

Завершение миграции и переключение

По завершении миграции задание получит статус Успешно мигрировало.

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

Важно

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

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

В меню проекта представлена опция Скачать отчёт, доступная при выборе заданий со статусом Успешно мигрировало. Функция позволяет выгрузить xlsx-отчёт с перечнем успешно смигрированных заданий для удобства документирования итогов миграций. Формат отчёта зависит от языка пользовательского интерфейса.

Миграция с автоматическим созданием приёмника

Выполните последовательность шагов:

Проверьте исходное состояние: источник запущен и доступен по сети.
Создайте в графическом интерфейсе MIND Migrate #guest новый проект, в рамках которого будут группироваться миграционные задания.
Создайте платформу.
Добавьте размещение.
Создайте миграционное задание, выберите размещение и укажите вариант связи источника: автосоздание приёмника.
Уточните параметры задания, выберите размещение и сопоставьте сети.
Сохраните задание и отправьте его на проверку.
Запустите миграцию.
Инициируйте завершение миграции и выполните переключение.

Создание нового проекта

Выполняется в соответствии с информацией, приведённой в разделе Выполнение миграции > С ручным созданием приёмника > Создание нового проекта.

Создание платформы

Создайте в интерфейсе MIND Migrate #guest новую платформу. Для этого в разделе Автоматизация на вкладке Платформы нажмите кнопку + Добавить платформу.

В открывшемся окне заполните поля:

В поле Имя платформы введите её название.
В поле Описание добавьте краткое описание платформы.
В поле Адрес подключения укажите полный URL-адрес подключения к целевой платформе.

Примечание

Для vCloud Director укажите адрес подключения в формате: <fqdn>/api.

Для OpenStack укажите Identity URL с портом, например: http://openstack.example.com:5000. Если порт не указан, сохранить платформу не получится. Порт по умолчанию — 5000.
Если флажок Игнорировать проверку сертификата не установлен, платформа требует проверки сертификата для установления безопасного соединения. При использовании платформой самоподписанных сертификатов, рекомендуется установить флажок Игнорировать проверку сертификата. При использовании сертификатов от корпоративного или публичного Удостоверяющего Центра, рекомендуется импортировать сертификаты корневого и промежуточных УЦ на контроллере и убрать флажок Игнорировать проверку сертификата.
Выберите тип платформы из выпадающего списка.
Выберите версию платформы — это API, с которым будет работать драйвер MIND. Рекомендуется выбирать последнюю доступную версию.
Выберите существующие из списка или добавьте новые ключи доступа. Подробная информация по работе с ключами приведена в разделе Ключи доступа.
В зависимости от типа платформы заполните поля Логин и Пароль следующими данными:
- VMware vSphere: логин и пароль. Для работы функции импорта машин источников с платформы VMware vSphere достаточно указать параметры учётной записи, имеющей права на чтение (роль Read-Only) на платформу виртуализации. Для создания машин приёмников требуется указать параметры учётной записи, имеющей права на создание ВМ из шаблонов, редактирование параметров ВМ, подключение ВМ к виртуальным коммутаторам, запуск и остановку ВМ, создание и подключение виртуальных дисков (например, роль Administrator) на платформу виртуализации;
- vCloud Director: логин и пароль;
- Basis Dynamix Enterprise: ID Приложения (логин) и API Ключ (пароль). Подробнее см. в документе «Руководство по использованию API пользователя», доступном для загрузки на сайте производителя https://basis.ru/docs;
- OpenStack: логин и пароль;
- SpaceVM: логин и пароль;
- oVirt: логин и пароль.

Нажмите Сохранить. Сохранённая платформа отобразится в списке платформ Пользователя.

Определение контекста для платформ

После создания платформ можно определить контекст для платформ.

Контекст — это дополнительный параметр подключения, который требуется для некоторых типов платформ. Он уточняет способ авторизации или указывает рабочую область внутри платформы. Если же платформа использует единую точку входа, а учётная запись имеет полный обзор ресурсов, контекст не требуется.

Для Basis Dynamix Enterprise:

Нажмите на созданной платформе.
Выберите пункт Определить контекст.
В открывшейся форме укажите URL-адрес авторизационного сервера (Basis SSO). Этот адрес отличается от адреса подключения к панели управления и используется для получения API-ключей.
Нажмите Сохранить.

Для vCloud Director:

Нажмите на созданной платформе.
Выберите пункт Определить контекст.
В открывшейся форме укажите имя тенанта в vCloud Director.
Нажмите Сохранить.

Для OpenStack:

Нажмите на созданной платформе.
Выберите пункт Определить контекст.
В открывшейся форме укажите имя домена в OpenStack.
Нажмите Сохранить.

Добавление размещения

Создайте размещение, с помощью которого можно оптимизировать создание приёмников на платформе. Для этого в интерфейсе MIND Migrate #guest нажмите кнопку + Создаем новое размещение.

Откроется мастер создания и настройки размещений:

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

Информация о создании размещения для каждой платформы приведена в разделах:

Basis Dynamix Enterprise
VMware vSphere
vCloud Director
OpenStack
SpaceVM
oVirt

Basis Dynamix Enterprise

На первом шаге мастера выберите провайдера Basis Dynamix Enterprise и задайте имя размещения.
Выберите учётную запись и ресурсную группу.
Укажите идентификаторы образов операционных систем, которые будут использоваться для развёртывания виртуальной машины. Для автоматического создания приёмников укажите идентификаторы образов Linux и Windows. Если идентификатор образа для одной из ОС не указан, автоматическое создание приёмников для соответствующей ОС будет недоступно.

Как получить идентификаторы образов, см. Подготовка шаблонов для автоматического создания виртуальных машин. Для Basis используйте цифровой идентификатор из раздела Images.
Выберите систему хранения данных и пул для размещения.
Выберите тип, ID сети, укажите шлюз основной сети и введите DNS для использования на приёмнике. При желании можно добавить несколько сетей.
Перейдите к шагу подтверждения конфигурации.

Завершите создание размещения: нажмите Протестировать для проверки настроек, затем — Подтвердить конфигурацию для сохранения размещения.

VMware vSphere

На первом шаге мастера выберите провайдера VMware vSphere и задайте имя размещения.

Если отобразилось окно подключения к SecMan, введите логин, пароль и пароль OTP, затем продолжите настройку.
Выберите место расположения виртуальных машин, заполнив поля значениями из выпадающего списка.
Выберите папку, в которой будут сохраняться создаваемые ресурсы.
Укажите идентификаторы образов операционных систем, которые будут использоваться для развёртывания виртуальной машины. Для автоматического создания приёмников укажите идентификаторы образов Linux и Windows. Если идентификатор образа для одной из ОС не указан, автоматическое создание приёмников для соответствующей ОС будет недоступно.

Для VMware vSphere введите путь в формате: /<Имя_датацентра>/vm/<Название_папки_с_шаблонами_VM>/<Имя_шаблона>.

Пример: /Datacenter/vm/Templates/target-ubuntu-20.04.

Важно

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

Завершите создание размещения: нажмите Протестировать для проверки настроек, затем — Подтвердить конфигурацию для сохранения размещения.

vCloud Director

На первом шаге мастера выберите провайдера vCloud Director и задайте имя размещения.
Задайте параметры размещения ресурсов, включая виртуальные датацентры (VDC) и настройки vApp, значениями из выпадающего списка.
Укажите параметры загрузки и размещения образов ОС, включая каталоги и образы для ОС Linux и ОС Windows. Для автоматического создания приёмников укажите образы для Linux и Windows. Если образ для одной из ОС не указан, автоматическое создание приёмников для соответствующей ОС будет недоступно.
Укажите параметры хранилища в vCloud Director.
Выберите тип, ID сети, укажите шлюз основной сети и введите DNS для использования на приёмнике. При желании можно добавить несколько сетей.
Перейдите к шагу подтверждения конфигурации.

Завершите создание размещения: нажмите Протестировать для проверки настроек, затем — Подтвердить конфигурацию для сохранения размещения.

OpenStack

На первом шаге мастера выберите провайдера OpenStack и задайте имя размещения.

Если отобразилось окно подключения к SecMan, введите логин, пароль и пароль OTP, затем продолжите настройку.
Выберите проект и ресурсную группу. При желании выберите место расположения виртуальных машин.
Укажите идентификаторы образов операционных систем, которые будут использоваться для развёртывания виртуальной машины. Для автоматического создания приёмников укажите идентификаторы образов Linux и Windows. Если идентификатор образа для одной из ОС не указан, автоматическое создание приёмников для соответствующей ОС будет недоступно.

Как получить идентификаторы образов, см. Подготовка шаблонов для автоматического создания виртуальных машин. Для OpenStack используйте цифровой идентификатор из раздела Images.
Выберите хранилище из выпадающего списка.
Выберите тип, ID сети, укажите шлюз основной сети и введите DNS для использования на приёмнике. При желании можно добавить несколько сетей.

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

Завершите создание размещения: нажмите Протестировать для проверки настроек, затем — Подтвердить конфигурацию для сохранения размещения.

SpaceVM

На первом шаге мастера выберите провайдера SpaceVM и задайте имя размещения.
Выберите организацию и пул ресурсов.
Выберите из списка шаблоны операционных систем, которые будут использоваться для развёртывания виртуальной машины. Для автоматического создания приёмников выберите шаблоны для Linux и Windows. Если шаблон для одной из ОС не выбран, автоматическое создание приёмников для соответствующей ОС будет недоступно.
Выберите хранилище из выпадающего списка.
Выберите сеть, укажите шлюз основной сети и введите DNS для использования на приёмнике. При желании можно добавить несколько сетей.

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

Завершите создание размещения: нажмите Протестировать для проверки настроек, затем — Подтвердить конфигурацию для сохранения размещения.

oVirt

На первом шаге мастера выберите провайдера oVirt и задайте имя размещения.
Выберите место расположения виртуальных машин, заполнив поля значениями из выпадающего списка.
Выберите шаблоны виртуальных машин для Linux и Windows из выпадающего списка. Для автоматического создания приёмников выберите шаблоны для обеих поддерживаемых ОС. Если шаблон для одной из ОС не выбран, автоматическое создание приёмников для соответствующей ОС будет недоступно.
Выберите домены хранения из выпадающего списка.
Укажите сети, шлюз основной сети и введите DNS.
Перейдите к шагу подтверждения конфигурации.

Завершите создание размещения: нажмите Протестировать для проверки настроек, затем — Подтвердить конфигурацию для сохранения размещения.

Подготовка шаблонов для автоматического создания виртуальных машин

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

Шаблон для платформы Basis Dynamix Enterprise

Создайте ВМ в соответствии с требованиями MIND, описанными в разделе Подготовка к миграции.
Получите идентификатор образа в интерфейсе Basis в разделе Образы. Подробная информация приведена в документации Basis Dynamix Enterprise на сайте производителя.

Образ ВМ должен содержать предустановленный пакет cloud-init, включающий настройку:
- Basis-утилит;
- QEMU Guest Agent.
Загрузите образ на платформу.

Шаблоны для платформ VMware vSphere и Cloud Director

Создайте ВМ в соответствии с требованиями MIND, описанными в разделе Подготовка к миграции.
Подготовьте образ ВМ с предустановленным пакетом cloud-init, включающим настройку VMware Tools.
Получите идентификатор образа в интерфейсе VMware vSphere/Cloud Director:
- Откройте консоль vSphere/Cloud Director.
- Выберите вкладку Hosts and Clusters.
- Выберите образ.
- Откройте вкладку Summary.
- Найдите идентификатор образа. В зависимости от версии интерфейса он может отображаться:
  - на вкладке Summary;
  - в разделе Configuration или Settings.
Формат идентификатора – /<Имя_датацентра>/vm/<Название_папки_с_шаблонами_VM>/<Имя_шаблона>. Пример: /Datacenter/vm/Templates/target-ubuntu-20.04.

Важно

Вводите путь с учётом регистра.
Проведите кастомизацию машины в соответствии с требованиями vSphere/Cloud Director. Используйте официальную документацию VMware:
- База знаний VMware
- Документация vSphere по спецификациям кастомизации

Шаблон для платформы OpenStack

Добавьте в проект OpenStack базовый образ в формате qcow2 с установленным пакетом cloud-init (Ubuntu Server 20.04/Astra Linux 1.7.5/Windows 10/Windows Server 2016).
Получите ID образа командой:
```
openstack image list
```
Пример ID образа: d418c902-059e-48d6-9819-c16f312e5457.
Укажите ID образа в мастере настройки Размещения.

Шаблон для платформы SpaceVM

Для шаблонов ВМ рекомендуется указывать атрибут типа ОС: Windows/Linux.

При добавлении Размещения в разделе Автоматизация в веб-интерфейсе существующие на платформе шаблоны отображаются в раскрывающемся списке.

Шаблон для платформы oVirt/REDVirt

Подготовка шаблонов для ОС Linux

Создайте ВМ и установите на неё ОС Ubuntu 20.04.
Установите QEMU Guest Agent:
```
sudo apt install qemu-guest-agent
```
Настройте автоматический запуск QEMU Guest Agent:
```
sudo systemctl enable qemu-guest-agent
```
Выключите ВМ.
Создайте из ВМ шаблон. При создании шаблона выберите опцию Запечатать Шаблон (Seal Template (Linux only)).

Подготовка шаблонов для ОС Windows

Ознакомьтесь с официальным руководством по подготовке шаблонов для ОС Windows на сайте производителя платформы виртуализации.

Создание миграционного задания

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

В разделе Машины выберите необходимый источник со статусом ОК и нажмите на .

Важно

Если источник находится в статусе Создан, нажмите на и выберите Инвентаризация. После получения информации о машине источник получит статус ОК.
Выберите пункт Перенести. Это действие позволяет перейти к форме создания миграционного задания. Вы можете также выполнить переход к форме Новое задание через раздел Проекты. Подробная информация приведена в разделе Создание миграционного задания.
Введите название задания в поле Имя, установите тип машин, выберите источник.

Вы можете выбрать из уже добавленных на контроллер машин (всех или только тех, которые прошли инвентаризацию) или создать новые.

Чтобы создать новые машины, нажмите Новая машина и в открывшемся окне заполните обязательные поля для создания источника и приёмника (см. раздел Машины).
В поле Приёмник из выпадающего списка подставится значение Автоматическое создание.
В поле Выберите размещение выберите ранее созданное размещение из выпадающего списка. Если в выбранном размещении не указан шаблон для семейства ОС источника, автоматическое создание приёмника будет недоступно.
Нажмите кнопку Сохранить. Задание на перенос появится в списке миграционных заданий со статусом Только источник.
Выберите Конфигурировать.

Откроется окно для уточнения деталей задания:
Поля Название задания и Описание при желании можно отредактировать.
Ранее выбранное размещение также можно поменять, выбрав его из выпадающего списка. Если размещение было выбрано на этапе создания задания, оно автоматически отразится в поле Выберите размещение.
Укажите имя машины на платформе-приёмнике. При желании можно воспользоваться шаблоном именования. Всплывающая подсказка отображается при наведении на иконку . Информация в блоке Машина <название машины> подставляется автоматически из настроек размещения и информации, предоставленной в ходе создания задания.
- Если флажком отмечено поле Использовать шлюз из размещения, то приёмник будет использовать шлюз размещения.
- Если флажком отмечено поле Использовать DNS из размещения, то приёмник будет использовать DNS размещения.
Установите IP-адрес и MAC-адрес.
Установите флажок в поле Создание интерфейса в статусе down при желании отключения выбранного интерфейса при создании приёмника (для платформ oVirt и vSphere).
Если во время создания размещения было добавлено несколько сетей, то при нажатии на кнопку + Добавить будет предоставлена возможность выбора дополнительных сетей для создания интерфейса.

Важно

Если вы хотите автоматически создать приёмник в платформе Basis, то в поле IP-адреса укажите статический адрес за пределами диапазона целевой виртуальной сети (ViNS), эта машина создастся в выключенном состоянии, что является нормальным поведением платформы.
Нажмите кнопку Развернуть и подтвердите создание задания.

Важно

При автоматическом создании приёмника указываются стандартные порты: SSH-порт 22 и TCP-порт 8999. Если необходимо использовать другие порты, то после добавления машины на контроллер перейдите в редактирование приёмника в разделе Машины и укажите их.

Если все данные корректны, то запустится процесс переноса данных, а задание получит статус Развертывание.

По завершении процесса миграционное задание перейдёт в статус Создано. На целевой платформе в списке виртуальных машин отобразится новый приёмник.

Массовая миграция

Массовая миграция — это автоматизированный перенос группы виртуальных машин из одной инфраструктуры в другую на основе единого плана миграции – маршрута. Пользователь загружает в контроллер таблицу в .csv-формате, где каждая строка описывает одну миграционную пару «источник–приёмник». Для каждой пары автоматически создаётся отдельное задание на миграцию. Все задания выполняются по общему сценарию в составе маршрута массовой миграции.

Маршрут состоит из последовательных фаз. На каждой фазе MIND Migrate #guest параллельно обрабатывает все пары «источник–приёмник», переход к следующей фазе происходит только после завершения всех заданий на текущей фазе.

Важно

MIND Migrate #guest поддерживает массовые миграции с платформ Basis, VMware vCenter и OpenStack на платформу OpenStack.

Предварительная подготовка

Перед запуском массовой миграции:

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

Подробнее см. разделы Создание платформы и Добавление размещения.
Для каждой платформы создайте ключи доступа для виртуальных машин.
Убедитесь, что создан проект, в котором будет выполнена миграция.
Заполните таблицу в .csv-формате, где каждая строка описывает одну миграционную пару.

Описание и правила заполнения каждого поля шаблона см. в Приложении:
- Шаблоны файлов миграции;
- Правила заполнения файлов миграции.

Выполнение массовой миграции

В разделе Проекты перейдите в проект, в рамках которого будет проводиться массовая миграция.
Перейдите на вкладку Маршруты миграции и нажмите кнопку Добавить маршрут миграции.
В форме Создание маршрута массовых миграций скачайте csv-файл с нужным шаблоном миграции и заполните его.
Загрузите заполненный файл в контроллер:

На этом этапе выполняется первичная проверка структуры таблицы: если ошибки структуры будут обнаружены, скорректируйте данные и повторно загрузите файл.
Нажмите Далее.
Настройте параметры маршрута массовой миграции:
- Укажите Название маршрута.
- В поле Тип выберите вариант миграции:
  - Стандартная – выполняется в обычном режиме: импорт источников и приёмников > установка агентов > непрерывная миграция.
  - Двухшаговая – подготовительная часть миграции выполняется заранее, а финальный этап запускается только в регламентное окно. Перед установкой агентов на источники маршрут приостанавливается.
- При необходимости выберите Ключ источника и Ключ приёмника из выпадающих списков. Если ключи уже заданы в csv-файле, поля можно оставить пустыми.
- В блоке Режим выполнения выберите:
  - Непрерывный – маршрут выполняется без пауз, переход между фазами происходит автоматически.
  - Пошаговый – после завершения каждой фазы маршрут останавливается и ожидает подтверждения для перехода к следующей фазе.
- В блоке Что делать при ошибке укажите поведение маршрута:
  - Остановить – если хотя бы одно задание завершается с ошибкой, маршрут останавливается.
  - Игнорировать – если хотя бы одно задание завершается с ошибкой, оно помечается как сбойное и отображается на вкладке Подробности, а для остальных пар миграция продолжается.
Примечание

После создания маршрута режим выполнения можно изменить через API. Запущенный маршрут можно остановить через API; остановка выполняется после завершения текущей фазы.
В блоке Расширенные настройки:
- в разделе Общие настройки укажите, какие действия выполнять до и после миграции;
- выберите вариант в выпадающем списке Настройка загрузчика Grub;
- в разделе Настройки синхронизации при необходимости включите режим Flow;
- в разделе Передача данных укажите тип шифрования, порт, ограничение скорости передачи данных, количество потоков и значение MTU.
Нажмите Создать маршрут. Появится сообщение Маршрут успешно создан.
В проекте на вкладке Маршруты миграции найдите созданный маршрут и запустите его кнопкой Начать. Появится уведомление Маршрут успешно запущен.

В случае большого числа строк (100+ миграционных пар) операции могут занимать заметное время.
Наблюдайте за выполнением маршрута на странице Детали выполнения: от инициализации маршрута, установки и подключения агентов на источники до создания и проверки приёмников, настройки задания и переноса данных.

Важно

При импорте из vCenter убедитесь, что каждый сетевой интерфейс виртуальной машины имеет определённый IP-адрес. Если хотя бы один интерфейс остаётся без IP-адреса, процесс импорта может остановиться на этапе получения сетевых данных или завершиться по тайм-ауту. При этом сама машина может быть доступна по сети, но импорт не продолжится без полного набора IP-адресов. Такое поведение является текущей особенностью импорта и не рассматривается как ошибка.
После завершения маршрута:
- Если все строки обработаны успешно и по каждой паре создано и выполнено задание на миграцию — маршрут завершается со статусом Готово.
- Если в маршруте есть строки с ошибками — маршрут завершается со статусом Ошибка. Информации о фазе и тексте ошибки для каждой пары доступна по ссылке Подробности.

Созданный маршрут появится в списке маршрутов миграции со статусом Готово.

В общем списке маршрутов миграции не отображаются маршруты, перемещённые в архив.

Архивировать маршрут массовых миграций и удалить связанные объекты можно через API. Для архивирования используется запрос POST /route/archive.

Остановить маршрут или изменить режим его выполнения после создания можно через API-запрос POST /route/runcontrol. Маршрут остановится после завершения текущей фазы.

Приложение

Шаблоны файлов миграции

Basis-OpenStack

src_name, src_ctrlurl, src_accesurl, src_ostype, src_vaultid, src_rgid, tgt_name, tgt_ctrlurl,
tgt_vaultid, tgt_cpu, tgt_ram, tgt_osimage, tgt_storageid, tgt_voltype, tgt_project, tgt_avzone,
tgt_secgroup, tgt_flavor, tgt_nic01_ip, tgt_nic01_gw, tgt_nic02_ip, tgt_nic02_gw,
tgt_util_networkid, flow

vCenter-OpenStack

src_name, src_grouptag, src_ctrlurl, src_accesurl, src_ostype, src_vaultid, src_datacenter,
src_cluster, src_respool, src_folder, tgt_name, tgt_ctrlurl, tgt_vaultid, tgt_cpu, tgt_ram,
tgt_osimage, tgt_storageid, tgt_voltype, tgt_project, tgt_avzone, tgt_secgroup, tgt_keyname,
tgt_flavor, tgt_nic01_ip, tgt_nic01_gw, tgt_nic02_ip, tgt_nic02_gw, tgt_util_networkid, flow,
scriptmap

OpenStack-OpenStack

src_name, src_ctrlurl, src_accesurl, src_ostype, src_vaultid, src_projectid, tgt_name, tgt_ctrlurl,
tgt_vaultid, tgt_cpu, tgt_ram, tgt_osimage, tgt_storageid, tgt_voltype, tgt_project, tgt_avzone,
tgt_secgroup, tgt_flavor, tgt_nic01_ip, tgt_nic01_gw, tgt_nic02_ip, tgt_nic02_gw,
tgt_util_networkid, flow, scriptmap

Правила заполнения файлов миграции

Basis–OpenStack

Ключ	Обязательное поле	Формат	Описание
src_name	Да	string	Имя источника в исходной инфраструктуре; не является hostname гостевой ОС. Значение не может быть пустым
src_ctrlurl	Да	string	URL контроллера исходной инфраструктуры в формате https://IP_ADDRESS_or_FQDN:port. Должен совпадать с URL одной из Платформ, зарегистрированных в контроллере MIND
src_accesurl	Нет	string	URI, по которому источник доступен со стороны контроллера MIND
src_ostype	Да	string	Тип гостевой ОС источника: «linux» или «windows». В текущей версии поддерживается только значение «linux»
src_vaultid	Нет	string	GUID хранилища учётных данных для доступа в гостевую ОС источника. При отсутствии значения выполняется попытка получить необходимые учётные данные из контроллера исходной инфраструктуры и автоматически создать хранилище. При этом не все облака поддерживают управление учётными записями гостевых ОС ВМ или предоставление таких данных
src_rgid	Да	int	Идентификатор ресурсной группы в облаке Basis, в которой размещается источник
tgt_name	Нет	string	Имя приёмника в целевой инфраструктуре; не является hostname гостевой ОС. Если поле не заполнено, при создании приёмника используется имя источника с добавлением суффикса _target
tgt_ctrlurl	Да	string	URL контроллера целевой инфраструктуры в формате https://IP_ADDRESS_or_FQDN:port. Должен совпадать с URL одной из Платформ, зарегистрированных в контроллере MIND
tgt_vaultid	Нет	string	GUID хранилища учётных данных для доступа в гостевую ОС приёмника. При отсутствии значения выполняется попытка получить необходимые учётные данные из контроллера целевой инфраструктуры. При этом не все облака поддерживают управление учётными записями гостевых ОС ВМ или предоставление таких данных
tgt_cpu	Нет	int	Количество CPU приёмника
tgt_ram	Нет	int	Объём оперативной памяти приёмника в мегабайтах
tgt_osimage	Да	string	Идентификатор образа ОС в целевой инфраструктуре, на основе которого создаётся приёмник
tgt_storageid	Да	string	Идентификатор системы хранения данных в целевой инфраструктуре, на которой размещаются диски приёмника. Все диски создаются на одной и той же системе хранения
tgt_voltype	Нет	string	Тип тома в OpenStack, который используется при создании дисков приёмника
tgt_project	Да	string	GUID проекта в OpenStack, в рамках которого создаются приёмники. Проект должен быть доступен через Платформу, указанную в поле tgt_ctrlurl
tgt_avzone	Да	string	Имя availability zone в OpenStack, в которой создаются приёмники. Указанная зона должна быть доступна через Платформу, указанную в поле tgt_ctrlurl
tgt_secgroup	Да	string	Имя security group в OpenStack, которая назначается сетевым интерфейсам приёмника. Указанная группа должна быть доступна через Платформу, указанную в поле tgt_ctrlurl
tgt_flavor	Нет	string	Имя flavor в OpenStack, на основе которого создаётся приёмник. Flavor определяет виртуальные ресурсы приёмника, включая количество CPU, объём оперативной памяти и параметры диска. Если значение не указано, подходящий flavor подбирается автоматически
tgt_nic01_ip	Нет	string	IP-адрес, назначаемый первому сетевому интерфейсу приёмника. Если значение не указано, IP-адрес для данного интерфейса наследуется от соответствующего интерфейса источника. Сеть или подсеть в целевой инфраструктуре выбирается автоматически: используется первая доступная сеть/подсеть, диапазон адресов которой включает указанный IP-адрес
tgt_nic01_gw	Нет	string	Шлюз по умолчанию для первого сетевого интерфейса приёмника. Если значение не указано, может быть использован шлюз по умолчанию, настроенный для соответствующего интерфейса источника
tgt_nic02_ip	Нет	string	IP-адрес, назначаемый второму сетевому интерфейсу приёмника. Если значение не указано, IP-адрес для данного интерфейса наследуется от соответствующего интерфейса источника. Сеть или подсеть в целевой инфраструктуре выбирается автоматически: используется первая доступная сеть/подсеть, диапазон адресов которой включает указанный IP-адрес
tgt_nic02_gw	Нет	string	Шлюз по умолчанию для второго сетевого интерфейса приёмника. Если значение не указано, может быть использован шлюз по умолчанию, настроенный для соответствующего интерфейса источника
tgt_util_networkid	Нет	string	GUID подсети (subnet) в OpenStack, используемой в качестве миграционной сети. Если значение параметра задано, на время миграции помимо основных сетевых интерфейсов на приёмнике создаётся дополнительный сетевой интерфейс, подключённый к указанной подсети. Этот интерфейс используется как предпочтительный канал для взаимодействия контроллера с приёмником. Функциональность автоматического удаления этого интерфейса после успешной миграции планируется в следующих релизах
flow	Нет	string	Признак использования режима Flow для данной миграционной пары. Укажите `yes`, если режим Flow требуется; укажите `no` или оставьте поле пустым, если режим Flow не используется

vCenter–OpenStack

Ключ	Обязательное поле	Формат	Описание
src_name	Да	string	Имя источника в исходной инфраструктуре; не является hostname гостевой ОС. Значение не может быть пустым
src_grouptag	Нет	string	Произвольная метка группировки источников vCenter. Используется для логического объединения источников при миграции
src_ctrlurl	Да	string	URL контроллера исходной инфраструктуры в формате https://IP_ADDRESS_or_FQDN:port. Должен совпадать с URL одной из Платформ, зарегистрированных в контроллере MIND
src_accesurl	Нет	string	URI, по которому источник доступен со стороны контроллера MIND
src_ostype	Да	string	Тип гостевой ОС источника: «linux» или «windows». В текущей версии поддерживается только значение «linux»
src_vaultid	Да	string	GUID хранилища учётных данных для доступа в гостевую ОС источника. При отсутствии значения выполняется попытка получить необходимые учётные данные из контроллера исходной инфраструктуры и автоматически создать хранилище. При этом не все облака поддерживают управление учётными записями гостевых ОС ВМ или предоставление таких данных
src_datacenter	Да	string	Имя виртуального датацентра vCenter в исходной инфраструктуре, в котором размещается источник
src_cluster	Да	string	Имя кластера vCenter в исходной инфраструктуре, в котором размещается источник
src_respool	Нет	string	Имя пула ресурсов vCenter в исходной инфраструктуре, в котором размещается источник
src_folder	Нет	string	Имя папки vCenter в исходной инфраструктуре, в которой размещается источник
tgt_name	Нет	string	Имя приёмника в целевой инфраструктуре; не является hostname гостевой ОС. Если поле не заполнено, при создании приёмника используется имя источника с добавлением суффикса _target
tgt_ctrlurl	Да	string	URL контроллера целевой инфраструктуры в формате https://IP_ADDRESS_or_FQDN:port. Должен совпадать с URL одной из Платформ, зарегистрированных в контроллере MIND
tgt_vaultid	Нет	string	GUID хранилища учётных данных для доступа в гостевую ОС приёмника. При отсутствии значения выполняется попытка получить необходимые учётные данные из контроллера целевой инфраструктуры. При этом не все облака поддерживают управление учётными записями гостевых ОС ВМ или предоставление таких данных
tgt_cpu	Нет	int	Количество CPU приёмника
tgt_ram	Нет	int	Объём оперативной памяти приёмника в мегабайтах
tgt_osimage	Да	string	Идентификатор образа ОС в целевой инфраструктуре, на основе которого создаётся приёмник
tgt_storageid	Да	string	Идентификатор системы хранения данных в целевой инфраструктуре, на которой размещаются диски приёмника. Все диски создаются на одной и той же системе хранения
tgt_voltype	Нет	string	Тип тома в OpenStack, который используется при создании дисков приёмника
tgt_project	Да	string	GUID проекта в OpenStack, в рамках которого создаются приёмники. Проект должен быть доступен через Платформу, указанную в поле tgt_ctrlurl
tgt_avzone	Да	string	Имя availability zone в OpenStack, в которой создаются приёмники. Указанная зона должна быть доступна через Платформу, указанную в поле tgt_ctrlurl
tgt_secgroup	Да	string	Имя security group в OpenStack, которая назначается сетевым интерфейсам приёмника. Указанная группа должна быть доступна через Платформу, указанную в поле tgt_ctrlurl
tgt_keyname	Нет	string	Имя ключа в OpenStack
tgt_flavor	Нет	string	Имя flavor в OpenStack, на основе которого создаётся приёмник. Flavor определяет виртуальные ресурсы приёмника, включая количество CPU, объём оперативной памяти и параметры диска. Если значение не указано, подходящий flavor подбирается автоматически
tgt_nic01_ip	Нет	string	IP-адрес, назначаемый первому сетевому интерфейсу приёмника. Если значение не указано, IP-адрес для данного интерфейса наследуется от соответствующего интерфейса источника. Сеть или подсеть в целевой инфраструктуре выбирается автоматически: используется первая доступная сеть/подсеть, диапазон адресов которой включает указанный IP-адрес
tgt_nic01_gw	Нет	string	Шлюз по умолчанию для первого сетевого интерфейса приёмника. Если значение не указано, может быть использован шлюз по умолчанию, настроенный для соответствующего интерфейса источника
tgt_nic02_ip	Нет	string	IP-адрес, назначаемый второму сетевому интерфейсу приёмника. Если значение не указано, IP-адрес для данного интерфейса наследуется от соответствующего интерфейса источника. Сеть или подсеть в целевой инфраструктуре выбирается автоматически: используется первая доступная сеть/подсеть, диапазон адресов которой включает указанный IP-адрес
tgt_nic02_gw	Нет	string	Шлюз по умолчанию для второго сетевого интерфейса приёмника. Если значение не указано, может быть использован шлюз по умолчанию, настроенный для соответствующего интерфейса источника
tgt_util_networkid	Нет	string	GUID подсети (subnet) в OpenStack, используемой в качестве миграционной сети. Если значение параметра задано, на время миграции помимо основных сетевых интерфейсов на приёмнике создаётся дополнительный сетевой интерфейс, подключённый к указанной подсети. Этот интерфейс используется как предпочтительный канал для взаимодействия контроллера с приёмником. Функциональность автоматического удаления этого интерфейса после успешной миграции планируется в следующих релизах
flow	Нет	string	Признак использования режима Flow для данной миграционной пары. Укажите `yes`, если режим Flow требуется; укажите `no` или оставьте поле пустым, если режим Flow не используется
scriptmap	Нет	string	ID сценария, применяемого к миграционной паре. Используется для сопоставления сценариев автоматизации на этапах миграции

OpenStack–OpenStack

Ключ	Обязательное поле	Формат	Описание
src_name	Да	string	Имя источника в исходной инфраструктуре; не является hostname гостевой ОС. Значение не может быть пустым
src_ctrlurl	Да	string	URL контроллера исходной инфраструктуры в формате https://IP_ADDRESS_or_FQDN:port. Должен совпадать с URL одной из Платформ, зарегистрированных в контроллере MIND
src_accesurl	Нет	string	URI, по которому источник доступен со стороны контроллера MIND
src_ostype	Да	string	Тип гостевой ОС источника: «linux» или «windows». В текущей версии поддерживается только значение «linux»
src_vaultid	Нет	string	GUID хранилища учётных данных для доступа в гостевую ОС источника. При отсутствии значения выполняется попытка получить необходимые учётные данные из контроллера исходной инфраструктуры и автоматически создать хранилище. При этом не все облака поддерживают управление учётными записями гостевых ОС ВМ или предоставление таких данных
src_projectid	Да	string	GUID проекта в OpenStack, в рамках которого размещается источник
tgt_name	Нет	string	Имя приёмника в целевой инфраструктуре; не является hostname гостевой ОС. Если поле не заполнено, при создании приёмника используется имя источника с добавлением суффикса _target
tgt_ctrlurl	Да	string	URL контроллера целевой инфраструктуры в формате https://IP_ADDRESS_or_FQDN:port. Должен совпадать с URL одной из Платформ, зарегистрированных в контроллере MIND
tgt_vaultid	Нет	string	GUID хранилища учётных данных для доступа в гостевую ОС приёмника. При отсутствии значения выполняется попытка получить необходимые учётные данные из контроллера целевой инфраструктуры. При этом не все облака поддерживают управление учётными записями гостевых ОС ВМ или предоставление таких данных
tgt_cpu	Нет	int	Количество CPU приёмника
tgt_ram	Нет	int	Объём оперативной памяти приёмника в мегабайтах
tgt_osimage	Да	string	Идентификатор образа ОС в целевой инфраструктуре, на основе которого создаётся приёмник
tgt_storageid	Да	string	Идентификатор системы хранения данных в целевой инфраструктуре, на которой размещаются диски приёмника. Все диски создаются на одной и той же системе хранения
tgt_voltype	Нет	string	Тип тома в OpenStack, который используется при создании дисков приёмника
tgt_project	Да	string	GUID проекта в OpenStack, в рамках которого создаются приёмники. Проект должен быть доступен через Платформу, указанную в поле tgt_ctrlurl
tgt_avzone	Да	string	Имя availability zone в OpenStack, в которой создаются приёмники. Указанная зона должна быть доступна через Платформу, указанную в поле tgt_ctrlurl
tgt_secgroup	Да	string	Имя security group в OpenStack, которая назначается сетевым интерфейсам приёмника. Указанная группа должна быть доступна через Платформу, указанную в поле tgt_ctrlurl
tgt_flavor	Нет	string	Имя flavor в OpenStack, на основе которого создаётся приёмник. Flavor определяет виртуальные ресурсы приёмника, включая количество CPU, объём оперативной памяти и параметры диска. Если значение не указано, подходящий flavor подбирается автоматически
tgt_nic01_ip	Нет	string	IP-адрес, назначаемый первому сетевому интерфейсу приёмника. Если значение не указано, IP-адрес для данного интерфейса наследуется от соответствующего интерфейса источника. Сеть или подсеть в целевой инфраструктуре выбирается автоматически: используется первая доступная сеть/подсеть, диапазон адресов которой включает указанный IP-адрес
tgt_nic01_gw	Нет	string	Шлюз по умолчанию для первого сетевого интерфейса приёмника. Если значение не указано, может быть использован шлюз по умолчанию, настроенный для соответствующего интерфейса источника
tgt_nic02_ip	Нет	string	IP-адрес, назначаемый второму сетевому интерфейсу приёмника. Если значение не указано, IP-адрес для данного интерфейса наследуется от соответствующего интерфейса источника. Сеть или подсеть в целевой инфраструктуре выбирается автоматически: используется первая доступная сеть/подсеть, диапазон адресов которой включает указанный IP-адрес
tgt_nic02_gw	Нет	string	Шлюз по умолчанию для второго сетевого интерфейса приёмника. Если значение не указано, может быть использован шлюз по умолчанию, настроенный для соответствующего интерфейса источника
tgt_util_networkid	Нет	string	GUID подсети (subnet) в OpenStack, используемой в качестве миграционной сети. Если значение параметра задано, на время миграции помимо основных сетевых интерфейсов на приёмнике создаётся дополнительный сетевой интерфейс, подключённый к указанной подсети. Этот интерфейс используется как предпочтительный канал для взаимодействия контроллера с приёмником. Функциональность автоматического удаления этого интерфейса после успешной миграции планируется в следующих релизах
flow	Нет	string	Признак использования режима Flow для данной миграционной пары. Укажите `yes`, если режим Flow требуется; укажите `no` или оставьте поле пустым, если режим Flow не используется
scriptmap	Нет	string	ID сценария, применяемого к миграционной паре. Используется для сопоставления сценариев автоматизации на этапах миграции