Как перенести виртуальную машину с сервера Proxmox VE на Proxmox‑кластер?

Есть автономный сервер Proxmox с двумя ВМ, которые нужно перенести в недавно созданный Proxmox-кластер. План переноса: выключить ВМ, сделать бэкап, перенести файл бэкапа на кластер и выполнить восстановление. <br/> 1. Нужно ли до восстановления заранее создать на кластере ВМ с такими же параметрами, как на старом сервере? <br/> 2. Если в кластере уже есть ВМ с номерами 100 и 101, перезапишутся ли они при восстановлении — будет ли возможность выбрать другой ID или вариант действия?
  • 24 февраля 2026 г. 7:02
Ответы на вопрос 5
Коротко — да, ваш план рабочий и несложный. Ниже — подробности и ответы на ваши 2 вопроса + практические команды и нюансы.

Общий алгоритм (вариант с остановкой ВМ, как вы планируете)
- На старом хосте: выключаете ВМ (или используете режим snapshot/stop при создании бэкапа).
- Делаем бэкап: vzdump (для QEMU/KVM) или vzdump/pct (для LXC).
- Копируем файл бэкапа на хранилище в кластере (в тот storage, где Proxmox видит бэкапы).
- На кластере восстанавливаем бэкап на нужный узел/хранилище.

Примеры команд
- Создать бэкап (остановленная ВМ):
  - Для KVM: vzdump 101 --dumpdir /var/lib/vz/dump --mode stop --compress lzo
  - Для LXC: vzdump 102 --dumpdir /var/lib/vz/dump --mode stop --compress lzo
- Скопировать бэкап на кластер:
  - scp /var/lib/vz/dump/vzdump-qemu-101-*.vma.lzo root@pve-cluster:/var/lib/vz/dump/
  (либо положить в любое другое storage, к которому прикреплён кластер)
- Восстановить на целевом кластере:
  - Для KVM (CLI): qmrestore /var/lib/vz/dump/vzdump-qemu-101-*.vma.lzo NEWID --storage target-storage --node target-node
  - Для LXC (CLI): pct restore NEWID /var/lib/vz/dump/vzdump-lxc-102-*.tar.lzo --storage target-storage --node target-node
  - В GUI: Datacenter → Storage → Content → выбрать бэкап → Restore. В форме указываете VMID, target node, storage и т.д.

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

1) Нужно ли заранее создавать на кластере ВМ с такими же параметрами?
- Нет. При восстановлении бэкапа Proxmox автоматически создаёт конфигурацию ВМ/CT (CPU, RAM, сетевые интерфейсы, диски) согласно данным в бэкап-архиве. Не нужно заранее вручную создавать ВМ с тем же набором параметров. Только учтите следующие моменты:
  - Хранилище: при восстановлении нужно выбрать целевое storage. Тип хранилища должен поддерживать нужные дисковые образы (например local-lvm, ZFS, Ceph и т.п.). Если выберете неподдерживаемое — восстановление не получится.
  - Сетевые имена/бриджи: конфиг сети из бэкапа будет восстановлен «как есть». Если на новом кластере сеть устроена иначе (имена мостов/вланов), после восстановления нужно поправить сетевые настройки.
  - Если используете cloud-init/ssh-keys — проверьте настройки после восстановления.
  - Для HA/Shared storage: если хотите иметь возможность миграции между нодами без копирования дисков, используйте shared storage (Ceph, NFS, iSCSI/TVS и т.д.).

2) Если в кластере уже есть ВМ с ID 100 и 101, перезапишутся ли они при восстановлении — можно ли выбрать другой ID?
- Proxmox при восстановлении не перезапишет существующую VM автоматически. Поведение:
  - В GUI при Restore поле VMID по умолчанию показывает исходный ID из бэкапа, но вы можете вручную ввести любой свободный ID перед стартом восстановления.
  - В CLI команды qmrestore/pct restore требуют указать целевой VMID. Если указать ID, который уже занят — команда обычно завершится ошибкой («VM <id> already exists»), и восстановление не произойдёт.
- Варианты действий:
  - Выбрать другой свободный ID при восстановлении (рекомендуется).
  - Если вы хотите восстановить именно на тот же ID, сначала удалите существующую ВМ/CT (или её конфиг и диски) на кластере, затем восстановите — после удаления ID освободится.
  - Принудительного «безопасного» перезаписывания через UI нет (и перезаписать конфиг+диски «поверх» существующей ВМ нежелательно без явного удаления). Ручные обходы (удаление старой ВМ или удаление её конфа/disk и затем восстановление) — возможны, но действуйте аккуратно, чтобы не потерять нужные данные.

Дополнительные рекомендации и нюансы
- Убедитесь, что файл бэкапа находится в storage, который Proxmox индексирует (например /var/lib/vz/dump для локального storage), чтобы GUI видел бэкап.
- Если диски в бэкапе были на LVM/VG с тем же именем — при восстановлении нужно выбрать совместимое место хранения; в противном случае Proxmox перенесёт образ на выбранное storage.
- При использовании Ceph/RBD: лучше заранее настроить целевой Ceph storage в кластере и указать его при восстановлении.
- Перед массовой миграцией протестируйте восстановление на одной тестовой машине.
- Для больших/частых переносов подумайте о переносе на shared storage и использовании live-migration (если есть сеть/хранилище) — чтобы не делать бэкап/восстановление.

Если хотите, могу:
- Подготовить конкретные команды для ваших VM (вставьте их ID, имена storage и узлы).
- Перечислить конкретные проверки после восстановления (сеть, disk, cloud-init, MACs, qemu-guest-agent).
Сначала делаешь бэкап VM которую нужно перенести, получаешь условный файл vma.zst, (он упадёт в /var/lib/vz/dump/) переносишь его в локальное хранилище той ноды того кластера что требуется. Дальше на той ноде где должна будет жить твоя виртуалка создаешь пустую VM без диска, и уже туда подгружаешь тот бэкап как образ жесткого диска командой <br/> <pre><code>qm importdisk 102 yournameVM.vma.zst NE-Storage --format raw</code></pre> (находясь в директории где находится твой бэкап файл). Тут соответственно 102- это id твоей новой VM пустышки (номер какой нужно поменяй), yournameVM.vma.zst - название бэкап файла; NE-Storage - твоё хранилище где будет жить VM, ну и  формат. После этого лезешь в пункт hardware твоей VM пустышки и присоединяешь новообразовавшийся диск, сохраняешь и лезешь в пункт options и там в boot order выставляешь галочку на  новообразовавшемся диске и выставляешь порядок загрузки условно на первое место поставив его. PROFIT!
В кластере сделай клон машин 100 и 101, соответственно с другими номерами, а эти удали. <br/> <br/> Подключи этот Proxmox к новому кластеру, а потом просто смигрируй машины.
Все проще подключаешь отдельно стоящую ноду к кластеру миргрируешь vm и удаляешь из кластера ненужную ноду <br/> Если версии proxmox сильно разные может потребоватся обновление ноды до версии кластера <br/> <br/> 1.нет не нужно при бекапе(или миграции) vm файл конфигурации кладется рядом(внутрь архива) <br/> 2.номер при восстановлении назначается также как и при создании новой виртуалки следующий по порядку за последним номером, если ручное восстановление вроде спрашивает какой номер назначить но по умолчанию дает уникальный id
Не нужно <br/> Без разницы, можно выбрать нужный новый айди
Похожие вопросы