echo6-docs/vault/runbooks/pve-guest-park-and-adopt.md

title	type	tags	aliases	related	updated
Park a Proxmox Guest on the NAS and Re-Adopt It	runbook	proxmox storage		omv-add-nfs-share environment proxmox-onboard-node proxmox-create-ubuntu-vm pi-nas-omv-runbook	2026-08-14

Park a Proxmox Guest on the NAS and Re-Adopt It

Shut a guest down, archive the whole thing to pi-nas, rebuild or replace the node, then bring the guest back on any node in the cluster. This is the Proxmox equivalent of registering an orphaned VM from an ESXi datastore, and it is the supported way to free a node for rebuild without shared runtime storage.

The archive is self-contained and carries no reference to its origin host, so it can be restored to a different node, a different VMID, different storage, or a freshly reinstalled machine.

---

Prerequisites

The pinas-backup storage must exist. It was added 2026-08-14 and is visible on all five cluster nodes:

Setting	Value
Type	NFS, vers=3
Server	192.168.1.245 (pi-nas)
Export	/export/pvebackup
Backing disk	sdc1 — the 19 TB-free drive, deliberately not sdd1 (PeerTube)
Content	backup
Mount point	/mnt/pve/pinas-backup

Confirm before starting:

pvesm status | grep pinas-backup

Creating or recreating this share is covered in omv-add-nfs-share. General NAS build is pi-nas-omv-runbook.

---

1. Park the guest

--mode stop shuts the guest down cleanly, archives it, and leaves it stopped.

# container
vzdump 111 --mode stop --storage pinas-backup --compress zstd

# VM
vzdump 105 --mode stop --storage pinas-backup --compress zstd

Note the archive name it prints. Files land in /mnt/pve/pinas-backup/dump/:

vzdump-lxc-111-2026_08_14-10_22_31.tar.zst     # container
vzdump-qemu-105-2026_08_14-10_45_02.vma.zst    # VM

Compression is significant — a 50 GB container typically lands near 1.5 GB.

List what is parked:

pvesm list pinas-backup

2. Remove the guest from the source node

Only once the archive is verified present and non-zero. This is the destructive step.

pct destroy 111        # container
qm destroy 105         # VM

Skip this entirely if the plan is to wipe the node anyway.

3. Rebuild the node

Node rebuild is proxmox-onboard-node. The archive is untouched by anything done to the node.

4. Adopt it back

Run this on the node you want the guest to live on. The VMID and target storage are free choices — they do not have to match the original.

# container
pct restore 111 pinas-backup:backup/vzdump-lxc-111-2026_08_14-10_22_31.tar.zst \
  --storage local-lvm

# VM
qmrestore pinas-backup:backup/vzdump-qemu-105-2026_08_14-10_45_02.vma.zst 105 \
  --storage local-lvm

To clone rather than move, restore under a new VMID and leave the original in place.

5. Start and verify

pct start 111 && pct status 111
qm start 105 && qm status 105

Verify the service itself, not just that the guest is running. For anything with a web front end, follow headless-browser-page-verification.

---

Things that will bite you

Containers cannot live-migrate in PVE 9 at all. This is a hard platform limitation, not a configuration gap. Restart migration is the only option for LXC. VMs live-migrate normally when storage is shared.

Bind mounts and device mount points are not captured. vzdump skips their contents. Anything reached through a bind mount, a lxc.mount.entry, or virtiofs must be moved separately. This applies directly to recon-vm, whose nav, kiwix and library shares are virtiofs from the host — see navi-recon-separation.

Passthrough does not survive relocation. USB devices, PCI passthrough and custom args: reference host-specific paths. Guests using them need those recreated on the target node before they will start.

sdc has no redundancy. It is a single ext4 drive. An archive parked there dies with the drive — acceptable for a staging area you are actively pulling back from, not acceptable as the only copy of something. Only sda/sdb on pi-nas are mirrored.

Space is shared. /export/pvebackup and /export/arr sit on the same physical drive, so the ~19 TB free is not exclusively yours.

---

Why not shared runtime storage

Running guests directly off NFS was considered and rejected: container volumes are raw images, NFS snapshots require qcow2, so pct snapshot / pct rollback stops working — and that rollback path is what fleet-patch-audit depends on for safe patching. It would also make pi-nas a single point of failure for every guest on every node simultaneously.

Ceph was considered for the same goal. It needs a dedicated whole drive per node, and three of five nodes have no free drive bay; it also costs ~4 GB RAM per OSD on two nodes that are hard-capped at 32 GB. See fleet-storage-memory-upgrade.