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

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

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

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

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

Proxmox прямо приводит сценарий, где физический сервер и подготовленная VM загружаются с Clonezilla, после чего диск копируется по сети. [pve.proxmox](https://pve.proxmox.com/wiki/Advanced_Migration_Techniques_to_Proxmox_VE)

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

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

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

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

```bash
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

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

```bash
/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](https://pve.proxmox.com/wiki/Passthrough_Physical_Disk_to_Virtual_Machine_(VM))

Например:

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

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

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

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

## Что выбрать

| Ситуация | Рекомендуемый метод |
|---|---|
| Linux без сложной БД | Новая VM + `rsync` |
| Linux с большим количеством настроек | Clonezilla или полный образ |
| Windows Server | VSS/bare-metal backup или Disk2vhd/StarWind |
| Минимальный простой | Полный перенос + финальная синхронизация |
| Нужно только проверить запуск | Проброс физического диска |
| Сложная БД | Репликация или специализированный backup |
| Старый сервер с BIOS/MBR | Образ диска, затем проверка загрузчика |

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