Сервер 1С работает в Windows-ВМ на Hyper-V, а перенести его нужно на Proxmox. Долгая остановка не подходит: вы хотите заранее скопировать диск, проверить загрузку и только потом переключить пользователей. Обычный импорт VHDX здесь не поможет — перед qm importdisk исходную машину придётся выключить.
Основное копирование можно провести без остановки Windows. Для этого агент внутри гостевой ОС передаёт диск на Proxmox, а затем догоняет изменения по блокам. Короткое окно всё равно потребуется: остановить запись, закончить синхронизацию и запустить новую ВМ.
Прямого импорта ВМ из Hyper-V в Proxmox нет. По руководству WinITPro, Proxmox не принимает экспорт Hyper-V как готовую машину. Диск импортировать можно, но конфигурацию ВМ придётся собрать заново.
Почему копирование VHDX не даёт миграцию без простоя
Microsoft Disk2VHD снимает VHDX с работающей Windows через VSS — службу теневого копирования. На выходе вы получите онлайн-снимок диска. Но следующий этап, qm importdisk, остаётся холодным: WinITPro предписывает остановить исходную ВМ перед окончательным импортом.
С Export-VM и ручной конвертацией через qemu-img происходит то же самое. В файл попадёт состояние диска на момент копирования. Всё, что пользователи изменят позже, останется только на исходной ВМ.
| Способ | Что происходит с работающей ВМ | Что переносится | Когда подходит |
|---|---|---|---|
Export-VM в Hyper-V | ВМ останавливают для согласованного переноса | Конфигурация Hyper-V и VHDX | Допустимо окно на холодную миграцию |
| Disk2VHD через VSS | Windows продолжает работать во время создания VHDX | Снимок логических дисков | Нужен онлайн-образ для подготовки или архива |
qemu-img и qm importdisk | Рабочую ВМ выключают перед окончательным импортом | Диск VHDX с конвертацией в хранилище Proxmox | Можно остановить сервер на время переноса |
| Агент внутри Windows | Агент копирует диск и передаёт изменившиеся блоки | Рабочий диск и накопленные изменения | Надо вынести основное копирование за пределы окна переключения |
Вывод: если долгая остановка запрещена, средство конвертации VHDX задачу не решит. Нужна непрерывная репликация.
Разработчик i2Migration, компания Info2Soft, заявляет блочную репликацию и установку драйверов через агент. Это функция стороннего продукта, а не Proxmox. Сначала проверьте на тестовой ВМ лицензию, поддержку вашей версии Windows и порядок финальной синхронизации.
Сначала зафиксируйте путь назад
Исходная ВМ должна запускаться до конца миграции. Не удаляйте её, не меняйте системный диск и не назначайте ей новые роли, пока готовите копию.
Схема отката проста. Если целевая ВМ не проходит проверку, вы выключаете её и запускаете исходную на Hyper-V. Но после финального переключения обе копии нельзя включать одновременно.
До начала работ запишите параметры исходной машины:
- поколение Hyper-V;
- режим Secure Boot;
- число виртуальных процессоров и объём памяти;
- состав и порядок дисков;
- разметку разделов;
- MAC-адрес и сетевые настройки;
- имя Windows;
- роли 1С и СУБД;
- службы, которые должны стартовать автоматически;
- расположение лицензий 1С и способ их привязки.
Не надейтесь на память. Снимки экранов Hardware и Firmware быстрее покажут расхождение, если Windows не загрузится на новом гипервизоре.
Подготовьте целевой узел Proxmox
Создайте ВМ без рабочего системного диска. Режим загрузки должен совпасть с исходной машиной: Generation 1 работает через BIOS, Generation 2 — через UEFI.
Cloud-PVE связывает Hyper-V Generation 1 с BIOS, а Generation 2 — с UEFI. Для UEFI-гостя выберите в Proxmox прошивку OVMF и добавьте EFI-диск. Если на Hyper-V включён Secure Boot, отдельно проверьте его настройки и совместимость установленных драйверов.
| Параметр Hyper-V | Настройка Proxmox | Что проверить до переключения |
|---|---|---|
| Generation 1 | SeaBIOS | Системный раздел и порядок загрузки |
| Generation 2 | OVMF и EFI-диск | UEFI, Secure Boot и загрузочную запись Windows |
| VHDX на виртуальном SCSI-контроллере | VirtIO SCSI | Драйвер загружается до подключения системного диска |
| Сетевой адаптер Hyper-V | VirtIO Network | Драйвер установлен, параметры сети записаны |
| Аппаратная подпись Hyper-V | Новое виртуальное оборудование KVM | Состояние активации Windows и лицензий |
Вывод: одинакового размера диска и объёма памяти недостаточно. Windows должна увидеть контроллер, сетевую карту и тот режим загрузки, для которого установлена система.
Если узел Proxmox ещё не подготовлен, начните с инструкции по созданию ВМ и настройке ролей 1С в Proxmox. Она поможет настроить гипервизор, но рабочий диск не реплицирует.
Загрузите драйвер VirtIO до переноса системного диска
Windows на Hyper-V не загружает драйвер VirtIO SCSI, пока не увидит такой контроллер. Если сразу подключить к нему системный диск, загрузка может оборваться ошибкой доступа к загрузочному устройству.
WinITPro предлагает заранее выполнить скрипт load-virtio-scsi-on-boot. Он создаёт временное устройство VirtIO SCSI. Windows обнаруживает устройство, устанавливает драйвер и начинает загружать его при старте.
Подготовьте драйвер на исходной ВМ до финальной синхронизации:
- Подключите к Windows-ВМ актуальный ISO с драйверами VirtIO.
- Установите драйверы дискового контроллера и сетевого адаптера.
- Настройте автоматическую загрузку VirtIO SCSI через
load-virtio-scsi-on-boot. - Проверьте драйверы в диспетчере устройств.
- Если установщик требует перезапуск, перезагрузите исходную ВМ в согласованное окно.
- Проверьте, что службы 1С и СУБД снова работают.
Не оставляйте дисковый драйвер до первого запуска на Proxmox. После ошибки загрузки поставить его труднее: придётся менять контроллер или временно подключать другой диск.
Запустите блочную репликацию из Windows
Установите агент миграции внутри гостевой Windows. Он должен видеть системный диск, дополнительные тома и целевое хранилище Proxmox.
По описанию Info2Soft, i2Migration сначала передаёт весь диск, затем отправляет изменившиеся блоки и готовит драйверы. У другого продукта ищите тот же набор функций. Копирования VHDX по расписанию здесь мало.
Работы идут в таком порядке:
- Агент передаёт полный образ дисков на целевую сторону.
- Рабочая Windows продолжает принимать изменения.
- Агент вслед за основной копией отправляет изменившиеся блоки.
- На Proxmox создаётся KVM-ВМ с тем же режимом BIOS или UEFI.
- Реплицированный системный диск подключается через подготовленный контроллер.
- Перед переключением запускается последняя синхронизация.
Единого срока первой копии нет. Он зависит от объёма диска, скорости канала и количества новых записей во время переноса. Предварительную оценку даст выбранное средство после запуска репликации.
Одного процента выполнения тоже мало. Проверьте состав задания: туда должны попасть все нужные тома, включая отдельный диск СУБД, журналы транзакций и каталоги временных данных, если без них система не запустится штатно.
Согласуйте данные 1С и СУБД перед финальной синхронизацией
Блочная копия работающего диска ещё не доказывает, что база согласована. В документации Microsoft и Proxmox нет штатной процедуры, которая синхронизирует MS SQL Server или PostgreSQL при таком копировании. Поэтому обещать перенос 1С без операционного простоя нельзя.
Большая часть данных уйдёт без остановки Windows. Но перед последней синхронизацией запись нужно прекратить по правилам вашей СУБД:
- запретите новые сеансы 1С;
- завершите активные задания и обмены;
- остановите службы, которые пишут в базу;
- дождитесь завершения последней синхронизации агента;
- выключите исходную ВМ;
- только после этого запускайте копию.
Если сервер приложений и СУБД работают в разных ВМ, переключайте весь контур согласованно. Две копии, снятые в разные моменты, могут загрузиться. Это ещё не значит, что данные между ними согласованы.
Для распределённой или смешанной схемы заранее распишите порядок остановки ролей. Если порядок зависит от вашей конфигурации, закажите проверку плана миграции конкретного контура 1С до начала рабочего окна.
Не запускайте обе копии одновременно
После репликации обе ВМ получают одинаковое имя Windows, настройки служб и прикладные роли. В статической сети совпадёт и IP-адрес. Одновременный запуск создаст конфликт, а поведение клиентов станет непредсказуемым.
Первый тест новой ВМ проводите в изолированном сетевом сегменте. Если такого сегмента нет, отключите виртуальный сетевой адаптер до запуска.
В изоляции проверьте:
- загрузку Windows;
- наличие всех дисков и разделов;
- старт драйвера VirtIO SCSI;
- состояние диспетчера устройств;
- запуск служб СУБД и 1С;
- журналы Windows;
- состояние активации.
Не открывайте рабочую базу для записи сразу на двух копиях. Изолированный запуск нужен для проверки Windows и служб, а не для параллельной работы клона.
Проведите финальное переключение
Остановите прикладную запись в заранее согласованном порядке. Затем дождитесь финальной синхронизации агента и выключите исходную ВМ на Hyper-V.
Новую ВМ проверяйте снизу вверх:
- Windows загрузилась без восстановления загрузчика.
- Системный и дополнительные диски видны через VirtIO.
- Сетевой адаптер получил нужные параметры.
- Имя узла разрешается с рабочих мест.
- СУБД запустилась без ошибок восстановления.
- Службы сервера 1С работают.
- Один контрольный пользователь открыл базу.
- Типовой документ читается, а разрешённая проверочная операция выполняется.
- Регламентные задания стартуют только на новой ВМ.
Cloud-PVE и Vinchin предупреждают: после смены виртуального оборудования Windows может запросить повторную активацию. Проверьте её после первого рабочего запуска. Сначала добейтесь штатной загрузки, затем занимайтесь активацией.
После прикладной проверки удалите старые Hyper-V Integration Services. Такой порядок рекомендует руководство WinITPro: прежние интеграционные драйверы убирают только после успешного переноса.
Если пользователи замечают задержки, а Windows не показывает явной нагрузки, проверьте ресурсы ВМ, хранилище и физический узел. После смены гипервизора причина часто лежит за пределами гостевой ОС.
Сохраните исходную ВМ для отката
Не удаляйте Hyper-V-ВМ после первого успешного входа в базу. Оставьте её выключенной, пока не проверите рабочие операции, обмены, печать, фоновые задания и резервное копирование.
Перед откатом сначала выключите новую ВМ. Как только пользователи записали данные на Proxmox, старая копия отстала. Запускать её для продолжения работы без плана возврата данных нельзя.
Условия отката определите до миграции. Например: Windows не загружается, СУБД не поднимает базу, клиенты не подключаются, а нужный драйвер нельзя исправить за согласованное окно. Тогда решение уже записано — принимать его под давлением не придётся.
Контроллер домена переносите отдельно
Если та же Windows-ВМ выполняет роль контроллера домена, не копируйте её диск по описанной схеме. В отчёте Farid Saïd такой клон связывают с риском отката USN и скрытого повреждения репликации Active Directory.
Active Directory переносят иначе:
- Поднимите новый контроллер домена.
- Дождитесь репликации каталога.
- Проверьте DNS и состояние репликации.
- Передайте роли FSMO.
- Понизьте старый контроллер.
- Переносите роль сервера 1С отдельно.
Не обращайтесь с диском контроллера домена как с обычным клоном Windows-сервера. Когда AD, СУБД и 1С совмещены в одной ВМ, сложнее и перенос, и возврат на Hyper-V.
Холодный перенос оставьте запасным путём
Если средство агентной репликации не поддерживает вашу Windows или целевое хранилище, используйте холодную миграцию. Выключите ВМ, перенесите VHDX и импортируйте диск через qm importdisk.
По данным WinITPro, актуальные версии Proxmox распознают VHDX при импорте и конвертируют диск в формат целевого хранилища. Для ручной конвертации Cloud-PVE приводит qemu-img с выводом в qcow2 или raw.
Холодную схему легче контролировать. После выключения Hyper-V-ВМ диск больше не меняется. За эту простоту вы платите временем простоя: оно уйдёт на копирование, импорт и первый запуск.
Чек-лист перед открытием доступа
Перенос без остановки на этапе копирования требует агентной блочной репликации. Export-VM, Disk2VHD, qemu-img и qm importdisk подходят для холодной миграции или подготовки образа.
Перед переключением закройте семь пунктов:
- драйверы VirtIO установлены и загружаются;
- Generation 1 перенесена в SeaBIOS, Generation 2 — в OVMF;
- полная и финальная репликации завершены без ошибок;
- исходная ВМ выключена перед запуском рабочей копии;
- Windows, сеть, СУБД и службы 1С проверены;
- контрольный пользователь открыл базу;
- исходная ВМ сохранена выключенной для отката.
Остался хотя бы один незакрытый пункт — пользователей пока не переключайте. Продолжайте готовить копию, а исходный сервер оставьте в работе.