Переезд с Proxmox на другое железо: перенос виртуалок

MAATRIX

Железо стареет, дата-центр меняется, тарифы перестают устраивать — и рано или поздно встаёт вопрос: как перетащить десяток-другой виртуалок с одного Proxmox на другой, желательно без выходных, потраченных на пересборку систем с нуля. Разница принципиальная в зависимости от того, знают ли два сервера друг о друге: если это узлы одного кластера — задача решается штатными средствами за пару кликов или одной командой, если это два независимых Proxmox — придётся выгружать и загружать VM руками, и здесь есть где споткнуться.

Два сценария переезда: кластер и чужие друг другу серверы

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

Сценарий А: оба сервера уже в одном кластере Proxmox (объединены через pvecm, видят друг друга в веб-интерфейсе как ноды одного датацентра). Это самый комфортный случай: миграция VM — штатная операция, доступная из графического интерфейса или командой qm migrate.

Сценарий Б: серверы полностью независимы — разные инсталляции Proxmox, разные кластеры или вообще не объединены в кластер (частый случай при смене хостинг-провайдера или физическом переезде в другой ЦОД). Здесь штатной миграции нет — нужно экспортировать VM в переносимый формат и импортировать на другой стороне.

Если у вас есть возможность на время переезда временно объединить оба сервера в один кластер (когда они в одной сети и задержка между ними разумная) — это часто оправдано именно ради живой миграции, даже если потом кластер разъединяется обратно. Но в большинстве реальных переездов — особенно между разными дата-центрами или провайдерами — серверы остаются независимыми, и работает второй сценарий.

Живая и офлайн-миграция внутри одного кластера

Если серверы в одном кластере, самый простой путь — вкладка Datacenter → нужная VM → Migrate в веб-интерфейсе, либо из консоли:

qm migrate <vmid> <целевая-нода> --online

Флаг --online запускает живую миграцию — VM продолжает работать, память и состояние процессов переносятся в фоне, и в конце происходит короткое переключение (обычно доли секунды простоя сети). Это работает, только если:

• диски VM лежат на общем хранилище (Ceph, NFS, iSCSI) или используется --targetstorage с локальным сторэджем на целевой ноде (Proxmox тогда сам гоняет диск по сети во время миграции — дольше, но тоже без выключения);
• типы процессоров старого и нового хоста совместимы — это тот самый подводный камень, разберём отдельно ниже.

Если процессоры несовместимы (например, VM работает с CPU-типом host на Intel-ноде, а переезжает на AMD), живая миграция не пройдёт — Proxmox честно откажется с ошибкой о несовместимых флагах CPU. В этом случае доступна офлайн-миграция:

qm migrate <vmid> <целевая-нода>

Без --online Proxmox сначала выключает VM, переносит диск и конфиг, запускает на новой ноде. Дольше по простою (зависит от размера диска), зато не капризничает насчёт CPU — на старте VM просто получает набор инструкций заново под актуальное железо.

Практический момент: даже внутри кластера перед массовой миграцией стоит проверить qm config <vmid> на нестандартные параметры — проброшенные PCI-устройства (hostpciX), локальные точки монтирования, специфичные для конкретной ноды пути — такие VM живая миграция просто не подхватит, и это увидится только в момент попытки.

Перенос между независимыми серверами: vzdump, экспорт и импорт

Когда кластера нет, рабочий путь — снять бэкап встроенным vzdump и восстановить его на другой стороне через qmrestore. Это не «экспорт в OVF» в строгом смысле (Proxmox поддерживает и OVF/OVA для взаимодействия с VMware/VirtualBox через qm importovf, но для переезда Proxmox → Proxmox формат vzdump проще и надёжнее — сохраняет полную конфигурацию VM, а не только диск).

На исходном сервере:

vzdump 101 --mode snapshot --compress zstd --storage local --dumpdir /mnt/export

• --mode snapshot — снятие бэкапа без остановки VM (если хранилище поддерживает снапшоты; для LVM-thin, ZFS, Ceph — работает штатно);
• --compress zstd — сжатие на лету, заметно ускоряет передачу по сети за счёт меньшего объёма;
• результат — файл вида vzdump-qemu-101-2026_08_28-03_15_00.vma.zst плюс лог.

Передать файл на новый сервер можно несколькими способами:

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

# или через промежуточное хранилище (S3-совместимое, внешний диск, NFS)

На целевом сервере восстановление:

qmrestore /var/lib/vz/dump/vzdump-qemu-101-2026_08_28-03_15_00.vma.zst 101 --storage local-zfs

Proxmox создаст VM с тем же ID и конфигурацией (RAM, ядра, диски), но диск попадёт в указанный --storage — здесь важно заранее знать, какие хранилища вообще есть на новом сервере (pvesm status), иначе восстановление упадёт с ошибкой «storage not found».

Если ID виртуальной машины на новом сервере уже занят (например, там уже что-то работает под тем же номером) — укажите другой:

qmrestore /var/lib/vz/dump/vzdump-qemu-101-*.vma.zst 205 --storage local-zfs

Отдельно стоит сказать про массовый перенос: если VM много, есть смысл сначала прогнать vzdump для всех сразу (vzdump 101 102 103 --mode snapshot ... или вообще без списка ID — на весь узел), сложить архивы на общий стейджинг, и уже оттуда параллельно закачивать/восстанавливать — это быстрее, чем гонять пары VM туда-сюда по одной.

CPU: kvm64 против host — совместимость процессоров

Самая частая причина, по которой VM после переезда либо не мигрирует живьём, либо стартует и тут же падает в kernel panic / BSOD — несовпадение набора инструкций процессора.

Тип CPU задаётся в конфигурации VM (qm config <vmid> → строка cpu:):

Если VM создавалась с cpu: host на старом сервере, а новый — другой производитель или поколение, у вас два пути:

1. Заранее сменить тип CPU на kvm64 до переезда (можно прямо на старом сервере, VM ужмёт себе видимый набор инструкций и продолжит работать):

   qm set 101 --cpu kvm64

После этого VM спокойно живёт что на старом, что на новом железе — ценой небольшой потери производительности на нагрузках, которые упирались в специфичные инструкции (AVX-512 и подобное).

1. Смириться с обязательным выключением при переносе — офлайн-миграция или restore из бэкапа всё равно пересоздают VM с нуля на новом хосте, и если тип CPU там прописан как host, она просто заново подхватит набор инструкций нового процессора при следующем старте. Проблема живой миграции («на лету», без остановки) в том, что она пытается перенести уже запущенное состояние процессора между разными наборами инструкций — вот это как раз не работает при разном железе.

Итого: если переезд заведомо на другой производитель CPU — даже не пытайтесь настраивать живую миграцию, сразу планируйте офлайн-перенос (выключение + restore) и по возможности переключите тип CPU на kvm64 заранее, чтобы не ловить сюрпризов при следующем перезапуске VM уже на новом месте.

Драйверы дисков и сети внутри VM

Второй по частоте подводный камень — виртуальные устройства, которые видит гостевая ОС, могут быть не теми, что ожидает новый хост, особенно если старая VM создавалась давно или мигрировала из другой системы виртуализации.

Проверить стоит две вещи:

Диски. Современный Proxmox по умолчанию предлагает VirtIO SCSI или VirtIO Block — это самый быстрый и универсальный вариант, одинаково понимаемый любой версией Proxmox/QEMU. Если старая VM использует IDE или SATA эмуляцию (частый пережиток старых импортов или ручных настроек), диски всё равно перенесутся и заработают — но производительность будет хуже, а на новом сервере стоит сразу проверить qm config <vmid> на строки вида ide0:/sata0: и по возможности перевести на VirtIO уже после переноса, добавив драйверы внутри гостевой ОС (для Windows — через virtio-win ISO, для Linux — обычно уже встроены в ядро).

Сеть. То же самое с сетевыми картами: virtio — стандарт по умолчанию, e1000/rtl8139 — эмуляция под старые ОС без виртуальных драйверов. После восстановления VM на новом сервере обязательно проверьте qm config <vmid> | grep net:

net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0

Если модель — не virtio, а гостевая ОС (особенно старая Windows) не имеет нужного драйвера — сетевая карта в системе будет числиться, но не поднимется, и VM «потеряется» в сети сразу после переезда, хотя формально всё восстановилось штатно. Для Windows-гостей держите под рукой ISO с драйверами virtio-win ещё до переноса — вставить его в CD-привод VM и поставить драйверы можно и на старом сервере заранее, не дожидаясь переезда.

Объём данных, окно переноса и способ передачи

Перенос VM — это, по сути, перенос её дисков, и здесь всё упирается в банальную арифметику: сколько гигабайт/терабайт и по какому каналу.

Прикидка (условная, реальная скорость зависит от диска, сети и сжатия — не воспринимайте как гарантию):

• 100 Гбайт по гигабитному каналу с накладными расходами — реалистично рассчитывать на несколько часов, а не на 15 минут;
• сжатие zstd в vzdump обычно ощутимо сокращает объём для типичных систем (тексты, логи, база с индексами) — но почти не помогает для уже сжатых данных (видео, архивы, зашифрованные диски);
• если между серверами узкий канал или платный трафик — рассмотрите перенос через промежуточный внешний диск/NAS физически, либо через объектное хранилище (S3-совместимое) как буфер, а не гонять всё напрямую по интернету.

Практический план для объёма в несколько сотен гигабайт и выше:

1. Снять vzdump не в момент пиковой нагрузки (ночью/на выходных) — снапшот-режим не останавливает VM, но всё равно создаёт дополнительную дисковую нагрузку.
2. Передавать файлы бэкапов заранее, до финального окна простоя — если сервис не критичен к секундной консистентности, можно снять первый полный бэкап за сутки-двое до переезда, перекачать его не спеша, а в само окно переноса снять только «дельту» — повторный vzdump, который переносится уже быстрее (там, где инкрементальность поддерживается хранилищем, например Proxmox Backup Server; при простом vzdump в файл это будет просто второй полный бэкап, но с уже прогретым каналом закачки основной массы данных).
3. Держите отдельное окно простоя для финального восстановления и проверки — оно должно быть длиннее, чем «просто скопировать файл»: добавьте время на qmrestore, старт VM, проверку сети и сервисов внутри.

Если переносите сразу много VM — распараллеливайте передачу файлов (несколько потоков rsync или параллельная закачка), но не распараллеливайте сам vzdump на исходном сервере сверх меры — снятие нескольких бэкапов одновременно ощутимо грузит дисковую подсистему хоста и может замедлить работающие рядом VM, которые пока не переезжают.

Сеть и генеральная репетиция: vmbr до импорта, пилотная VM первой

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

Проверьте и настройте сеть на новом хосте до первого qmrestore:

cat /etc/network/interfaces

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

• имя моста совпадает с тем, что указано в конфиге VM (bridge=vmbr0 в строке net0 — если на новом сервере мост называется иначе или отсутствует, восстановленная VM не получит сеть при старте, хотя сама виртуалка запустится без ошибок);
• VLAN-теги (если использовались) настроены так же — tag= в конфиге VM должен совпадать с реальной VLAN-конфигурацией моста/аплинка на новом сервере;
• IP-адресация VM (если статическая, внутри гостевой ОС) соответствует новой сети — при переезде между разными дата-центрами или провайдерами внешний IP почти всегда меняется, и об этом нужно подумать заранее (DNS, firewall-правила, привязанные к старому IP).

Пример минимальной настройки моста на новом сервере под перенос:

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

После правки — systemctl restart networking или ifreload -a, и только затем восстанавливайте VM.

И последнее, но важное: не переносите сразу все VM. Возьмите одну некритичную виртуалку — тестовый стенд, второстепенный сервис, что-то, что можно уронить без последствий — и проведите с ней полный цикл: vzdump → передача → qmrestore → проверка сети → проверка приложения внутри. Такой пилот за 20-40 минут вскроет всё, что пойдёт не так на массовом переезде — несовпадающий мост, забытый storage, неверный тип CPU — и это будет стоить вам одной тестовой VM, а не простоя всей продакшн-инфраструктуры.

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