---
title: Park a Proxmox Guest on the NAS and Re-Adopt It
type: runbook
tags:
  - proxmox
  - storage
aliases: []
related:
  - [[omv-add-nfs-share]]
  - [[environment]]
  - [[proxmox-onboard-node]]
  - [[proxmox-create-ubuntu-vm]]
  - [[pi-nas-omv-runbook]]
updated: 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:

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

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

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

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

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

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