KarelWintersky / Physical-to-Virtual.md

Да. Это называется P2V — Physical-to-Virtual, то есть перенос физической машины в виртуальную машину Proxmox на базе QEMU/KVM. В Proxmox нет одной штатной кнопки «конвертировать работающий сервер», но есть несколько рабочих методов. Официальная документация описывает перенос через Clonezilla, dd и восстановление резервной копии. pve.proxmox

Основные варианты

1. Образ диска через Clonezilla

Наиболее универсальный и обычно безопасный способ:

1. Создать в Proxmox пустую VM с диском не меньше исходного.
2. Загрузить физическую машину с Clonezilla или SystemRescue.
3. Скопировать физический диск в виртуальный диск по сети.
4. Загрузить VM с получившегося диска.
5. Установить/перенастроить драйверы виртуального оборудования и загрузчик.

Proxmox прямо приводит сценарий, где физический сервер и подготовленная VM загружаются с Clonezilla, после чего диск копируется по сети. pve.proxmox

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

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

2. Онлайн-копирование работающего Linux

Для Linux можно передать содержимое диска или файловой системы на работающую VM через dd, partclone, rsync либо резервную систему:

dd if=/dev/sda bs=16M status=progress | \
  ssh root@proxmox-host 'dd of=/dev/zvol/rpool/data/vm-100-disk-0 bs=16M status=progress'

Но копирование всего /dev/sda на работающей системе имеет ограничения:

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

Для сервера с БД лучше сначала сделать дамп или использовать штатную репликацию, а не полагаться на «горячий» dd.

Более аккуратный Linux-вариант:

1. Создать новую VM с тем же или более новым дистрибутивом.
2. Перенести данные через rsync.
3. Восстановить конфигурацию и сервисы.
4. Переключить IP и DNS.

Для простого Debian/Ubuntu-сервера это часто лучше, чем тащить за собой старые драйверы и накопившиеся проблемы физической установки.

3. Резервная копия и восстановление

Если физический сервер уже резервируется, можно:

1. Сделать полный backup физической машины.
2. Создать VM в Proxmox.
3. Восстановить систему внутрь виртуального диска.
4. Исправить загрузчик и сетевую конфигурацию.

Этот путь особенно удобен для Linux, если используется bare-metal backup, например через vzdump-совместимый или файловый backup-инструмент. Но обычная копия файлов сама по себе не всегда является образом загрузочной системы.

4. StarWind, Disk2vhd и похожие конвертеры

Для Windows применяют:

• Disk2vhd;
• StarWind V2V Converter;
• Veeam Agent с bare-metal backup;
• Clonezilla;
• иногда qemu-img после получения образа диска.

Для Windows критичны:

• режим загрузки BIOS/MBR или UEFI/GPT;
• драйвер диска;
• виртуальный контроллер VirtIO;
• активация Windows;
• лицензирование приложений, привязанных к физическому железу;
• BitLocker и TPM.

На первом запуске лучше использовать максимально совместимое оборудование VM — например, SATA-диск и стандартный сетевой адаптер — а уже после успешной загрузки перейти на VirtIO.

Можно ли сделать без остановки?

Да, но с оговорками.

Варианты почти без простоя:

• сделать первый полный перенос работающей системы;
• затем выполнить повторную синхронизацию изменившихся данных через rsync;
• ненадолго остановить сервисы;
• перенести последние изменения;
• переключить IP на VM.

Для Linux-сервера с веб-приложением это может выглядеть так:

1. Полный rsync системы и данных.
2. Остановка Nginx/PHP-FPM/MySQL на физической машине.
3. Финальный rsync.
4. Исправление сетевой конфигурации в VM.
5. Запуск виртуальной машины.
6. Перенос IP или изменение DNS.

Для MariaDB/MySQL лучше использовать репликацию или хотя бы mysqldump/mariabackup, а не копировать файлы работающей базы через обычный rsync.

Для Windows обычно проще и надёжнее использовать VSS-aware backup: он создаёт согласованный снимок работающей системы.

Что обычно ломается после P2V

Linux

Чаще всего приходится проверить:

/etc/fstab
/etc/network/interfaces
/etc/netplan/*
/etc/default/grub

Возможные проблемы:

• сетевой интерфейс получил другое имя;
• старый MAC-адрес остался в конфигурации;
• initramfs не содержит нужного драйвера;
• загрузчик установлен на старый диск;
• изменились пути /dev/sdX;
• правила udev сохранили старую сетевую карту;
• включённый Secure Boot несовместим с конфигурацией VM.

Для первого запуска можно использовать:

• диск SATA или SCSI вместо VirtIO;
• сетевую карту e1000 вместо VirtIO;
• BIOS/SeaBIOS, если исходная система была BIOS;
• UEFI/OVMF, если исходная система была UEFI.

После загрузки всё можно постепенно перевести на VirtIO.

Windows

Проблемы обычно связаны с:

• отсутствием драйвера дискового контроллера;
• несовпадением BIOS/UEFI;
• HAL и старым железом;
• активацией;
• драйверами видеокарты;
• BitLocker/TPM;
• лицензиями, привязанными к серийному номеру или материнской плате.

Не следует сразу подключать диск как VirtIO, если в исходной Windows заранее нет соответствующего драйвера. Безопаснее сначала загрузиться с SATA, установить VirtIO-драйвер, а затем менять контроллер.

Отдельный вариант: проброс физического диска

Можно не копировать диск, а подключить физический диск к VM напрямую. Proxmox поддерживает добавление физического устройства по стабильному пути /dev/disk/by-id/.... pve.proxmox

Например:

qm set 100 -scsi0 /dev/disk/by-id/ata-SERIAL_NUMBER

Но это не полноценная миграция:

• диск остаётся физическим;
• он нельзя безопасно использовать одновременно физической ОС и VM;
• сложнее делать snapshots и backups;
• повышается риск повреждения данных;
• диск должен быть доступен хосту Proxmox.

Этот вариант полезен для временной проверки, но для постоянной эксплуатации лучше перенести данные в виртуальный диск или штатное хранилище Proxmox.

Что выбрать

Практически я бы рекомендовал для Linux-сервера сначала попробовать P2V-клон на отдельную VM, не отключая физическую машину. После проверки загрузки и сервисов — уже планировать короткое окно простоя для финальной синхронизации. Обязательно сохранить исходный диск нетронутым до тех пор, пока виртуальная копия не проработает хотя бы несколько дней.