Перенос виртуальных машин Proxmox на другой сервер

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

Дальше — разбор обоих сценариев: когда две машины видят друг друга как узлы одного кластера, и когда это два независимых Proxmox, между которыми нет ничего, кроме сети.

Сначала определите свой сценарий: от него зависит всё

Сценарий А — оба сервера в одном кластере Proxmox. Узлы знают друг о друге, есть общее хранилище (Ceph, NFS, ZFS поверх сети). Переезд — это одна команда, простой измеряется секундами или отсутствует.

Сценарий Б — два независимых сервера. Общего хранилища нет, узлы друг друга не видят. Путь один: снять дамп, перенести файл, восстановить на новом сервере. Это основная история — и именно в ней больше всего засад.

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

Сценарий А: переезд внутри одного кластера

Здесь всё решает общее хранилище. Если диски виртуалки лежат на Ceph/NFS и доступны обоим узлам, переезд делается на ходу:

qm migrate 101 pve02 --online

Пара проверок перед этим:

pvecm status — кворум жив, оба узла видят друг друга;
qm config 101 — убедиться, где лежат диски (scsi0, virtio0) и на каком хранилище;
свободное место на целевом узле, если диски локальные.

Если диски локальные, --online тоже возможен, но с копированием данных:

qm migrate 101 pve02 --online --with-local-disks

Простой в этом случае будет — на время переноса диска. Чем больше объём, тем длиннее пауза, поэтому сотни гигабайт так лучше не таскать.

Без общего хранилища остаётся офлайн-переезд: виртуалка выключается, конфиг и диски переезжают, включается на новом узле. Простой = время копирования. Это всё равно быстрее и надёжнее, чем путь через дампы.

Сценарий Б: два независимых сервера — дамп, передача, восстановление

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

Шаг 1. Снять дамп на исходном сервере

vzdump 101 --mode stop --compress zstd --dumpdir /mnt/transfer

Ключевые параметры:

--mode stop — виртуалка выключается, дамп получается консистентным. Так делают почти всегда: пара минут простоя дешевле, чем разбираться с битой базой на новом сервере.
--mode snapshot — без остановки, но только если хранилище поддерживает снимки (LVM-thin, ZFS, Ceph). Снимок — не гарантия, что приложение корректно перенесёт запись на диск во время копирования.
--mode suspend — компромисс: машина замирает на время копирования.
--compress zstd — сжатие. Для типовых данных экономит 30–50 % трафика.
--dumpdir — куда положить файл. Лучше сразу на отдельный диск или сетевой ресурс, а не в корень системного раздела.

Для контейнеров LXC команда та же — vzdump <id>, только дамп будет контейнерным.

Шаг 2. Передать файл

Варианты, от простого к удобному:

# напрямую по сети, с прогрессом
rsync -avP /mnt/transfer/vzdump-qemu-101-*.zst root@new-server:/var/lib/vz/dump/

# ограничить скорость, чтобы не задушить боевой канал
rsync -avP --bwlimit=50M /mnt/transfer/vzdump-qemu-101-*.zst root@new-server:/var/lib/vz/dump/

# ZFS: инкрементальная передача без промежуточного файла
zfs send -i tank/vm-101-disk-0@old tank/vm-101-disk-0@new | ssh new-server zfs receive tank/vm-101-disk-0

Промежуточное хранилище (внешний диск, NFS, S3-совместимое) удобно, когда серверы в разных сетях: дамп снимается вечером, утром восстанавливается. Ошибка — тащить терабайт «в лоб» днём и удивляться, почему у клиентов лагает сайт.

Шаг 3. Восстановить на новом сервере

qmrestore /var/lib/vz/dump/vzdump-qemu-101-2026_10_06-02_00_00.vma.zst 205 --storage local-lvm

Здесь важны две вещи. Первая — номер: можно восстановить под другим ID (205 вместо 101), если старый занят. Вторая — --storage: диски лягут на указанное хранилище, и там должно быть место.

Для контейнеров команда другая:

pct restore 107 /var/lib/vz/dump/vzdump-lxc-107-2026_10_06-02_00_00.tar.zst --storage local-lvm

После восстановления: qm config 205 — сверить параметры, qm start 205 — запустить, зайти в консоль, проверить сеть и сервисы. Не удаляйте оригинал, пока новая машина не отработает несколько дней.

Главная засада: тип CPU

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

cpu: host — виртуалка получает все инструкции текущего процессора. Работает быстрее всего, но привязывается к ним. Перенесли на железо с другим набором флагов — и машина либо не стартует, либо падает с ошибкой процессора.
cpu: kvm64 — обобщённый набор инструкций. Медленнее на несколько процентов, зато переезжает на любой x86-процессор. Разумный выбор для парка, который будет кочевать.
x86-64-v2 и подобные — компромисс: современнее kvm64, но требуют, чтобы целевой процессор их поддерживал.

Если переезд разовый и процессоры из одной семьи — можно оставить host, но сначала проверить флаги на обоих серверах:

lscpu | grep -i flags

Меняется тип CPU на лету, командой qm set 101 --cpu kvm64 — виртуалку после этого нужно перезагрузить. Дешевле сделать это до переезда, чем ловить «guest has not initialized the display» на новом сервере.

Диски: драйверы и место

Виртуальные диски подключаются как virtio/virtio-scsi (быстро) или как SATA/IDE (медленнее, но без требований к драйверам). Что проверить:

В Linux-госте драйверы virtio встроены в ядро — проблем не будет.
В Windows нужны драйверы virtio (ISO virtio-win). Если их нет, диск просто не определится, и машина уйдёт в «синий экран восстановления».
Место на целевом хранилище: df -h, lvs, zfs list — посмотреть заранее, а не в момент восстановления.
Толстые диски. Если диск выделен целиком, места нужно ровно столько же; thin-хранилища позволяют сэкономить.

Ещё одна мелочь, о которой вспоминают поздно: если в конфиге виртуалки был EFI-диск (UEFI) или TPM-состояние (Windows 11), qmrestore их не «додумает». Их переносят отдельно или пересоздают, иначе машина не загрузится.

Сеть: мост, MAC и два одинаковых IP

Мост на новом сервере нужно настроить до первого восстановления — иначе виртуалка поднимется без сети. Смотрим /etc/network/interfaces и сверяем, что название моста совпадает с указанным в конфиге виртуалки (net0: ... bridge=vmbr0).

Три правила переезда:

Не запускайте копию и оригинал одновременно. Два одинаковых IP в одной сети — это конфликт, а для баз данных ещё и риск разъехавшихся данных. Сначала выключить источник, потом включить копию.
MAC-адрес сохраняется в конфиге виртуалки. Если он поменяется, DHCP выдаст другой адрес, а статический конфиг внутри гостя останется старым — сеть отвалится. Проверяйте этот момент.
Правила фильтрации и firewall на новом сервере, если они привязаны к интерфейсам или адресам.

Что не переносится само

Об этом стоит знать заранее, чтобы не искать причину на новом сервере:

PCI-проброс (GPU, сетевые карты, HBA) — привязан к железу, переносится только руками и почти всегда не работает на другом сервере.
EFI-диск и TPM-состояние — для UEFI-машин и Windows 11.
ISO в CD-ROM — путь к образу на новом сервере будет другим; проще отключить привод.
Снапшоты — остаются на источнике. Если они нужны, используйте zfs send с дельтами или систему бэкапов уровня Proxmox Backup Server.
Лицензии, привязанные к железу или MAC.

Окно переноса: считайте заранее, а не в процессе

Простой при переезде — это не «час на дамп». Это время между выключением машины на источнике и успешным стартом на цели.

Порядок оценки:

Объём данных (du -sh по диску виртуалки, а не по файловой системе гостя — физический размер может отличаться).
Скорость канала: 1 Гбит/с — это примерно 100 МБ/с, то есть около 350 ГБ в час в идеале; со сжатием и реальными дисками смело делите на два.
Способ передачи: инкрементально (rsync после первого прогона) простой сокращается до минут — основная копия уже лежит на новом сервере.

Для парка машин делают две волны: сначала «холодные» сервисы, потом всё, что критично, — с заранее подготовленным откатом.

Генеральная репетиция: одна машина вместо всего парка

Перед боевым переездом прогоните полный путь на небоевой виртуалке: дамп → передача → восстановление → старт → проверка сети и сервисов. Это час работы, который экономит ночь.

Полезно проверять по пунктам:

машина загрузилась (не только «включилась»: UEFI/BIOS, порядок загрузки);
сеть отвечает, порты открыты, DNS резолвится;
сервисы стартуют сами после перезагрузки (systemctl is-enabled, автозапуск виртуалки onboot);
приложение видит базу и файлы по правильным путям;
время и часовой пояс верные;
бэкап-задание на новом сервере создано, иначе «переехали в тишину».

Чек-лист: до, во время, после

До переезда

Инвентарь: список ID, назначение, диски, размеры, зависимости между машинами.
Полный бэкап конфигов узла: /etc/pve/, /etc/network/interfaces, задания бэкапов.
Проверены флаги CPU, свободное место, версии Proxmox на обоих серверах.
Мост сети настроен на цели, IP не конфликтуют.
Есть тестовая виртуалка, на которой прогнан весь путь.

Во время

Источник остановлен, копия не запущена одновременно с ним.
Передача идёт вне пиковой нагрузки, при желании — с --bwlimit.
После восстановления сразу проверяются сеть, диск и логи запуска.

После

Машины работают, автозапуск включён, бэкапы на новом сервере настроены.
Оригиналы не удалены: оставьте их как откат на 3–7 дней, а лучше до первой проверки восстановления из бэкапа.
Старые диски и снапшоты вычищены — но после того, как новый сервер подтвердил стабильность.

Частые ошибки

Сделать vzdump с --mode snapshot и получить несогласованную базу.
Оставить cpu: host и перенести машину на другое железо.
Забыть про EFI/TPM и удивиться, что «виртуалка не грузится».
Включить копию, пока источник ещё работает: конфликт IP, а для СУБД — расходящиеся данные.
Не подготовить /etc/network/interfaces на новом сервере и остаться без сети.
Тащить дамп через боевой канал днём.
Удалить исходную машину в тот же день: откат после проверки — это не трусость, а инженерная гигиена.

Частые вопросы

Можно ли перенести виртуалку Proxmox без простоя?
Да, если оба сервера — узлы одного кластера и у них общее хранилище: qm migrate --online. Для двух независимых серверов непрерывного переезда нет: есть короткий простой или репликация уровня приложения (для сайтов — rsync и дамп базы, для отказоустойчивых схем — реплика базы).

Как перенести контейнер (LXC), а не виртуалку?
Тем же путём, но команды другие: vzdump <id> на источнике, pct restore <id> <файл> --storage <хранилище> на цели. Помните, что контейнеры используют ядро хоста: проверьте, что на новом сервере есть нужные модули (например, для Docker внутри контейнера) и совпадает тип — privileged или unprivileged.

Нужен ли Proxmox Backup Server?
Не обязателен для разового переезда, но для регулярных бэкапов он удобнее: инкрементальные копии, дедупликация, восстановление отдельных файлов и постоянная проверка целостности. Для одного-двух переездов хватит vzdump и qmrestore.

Что делать, если версии Proxmox на серверах разные?
Переносить дампом обычно можно, но обратный путь (с новой версии на старую) — нет. Перед переездом обновите оба узла до близких версий и проверьте pveversion; часть новых параметров машин старые версии просто не поймут.

Сколько занимает переезд 200 ГБ?
Считайте по каналу: около 30–60 минут при 1 Гбит/с и сжатии. Основное время уходит на передачу; сам простой измеряется минутами, если у вас уже лежит «почти полная» копия и остаётся докатить изменения.

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

Коротко

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

Если для переезда нужна вторая площадка, посмотрите VPS с root-доступом — в России и Европе, с NVMe и предсказуемыми дисками под виртуальные машины. Перед выкаткой полезно перечитать про бэкапы и перенос сайта на VPS: переезд и копии — это одна тема.