Skip to content

Reference: qm destroy vs pct destroy asymmetry on offline storage

Discovered during the 2026-05-31 late-evening bulk cleanup (SESSION-LOG.md Session 6). Not documented prominently in Proxmox docs but consistently reproducible.

The asymmetry

When a VM or LXC has a disk on a storage that is currently inactive (e.g. NFS share offline, host unreachable, network partition):

qm destroy <id> --purge — TOLERATES offline storage

  • Emits a warning per inaccessible disk: Could not remove disk 'fast:<id>/<file>', check manually: storage 'fast' is not online
  • Still removes the VM conf file (/etc/pve/qemu-server/<id>.conf)
  • Still purges the VM from related configurations (backup jobs, replication, HA)
  • Returns exit 0
  • Disk file is left orphaned on the offline storage; cleanup deferred until storage returns

pct destroy <id> --purge --force — REFUSES offline storage

  • Emits a single line: storage '<name>' is not online
  • Does NOT remove the conf file (/etc/pve/lxc/<id>.conf remains)
  • Does NOT modify any state
  • Returns exit 255
  • Container is still in pct list after the operation

This is consistent regardless of --force and --purge flags. pct destroy aborts hard at the storage-reachability check; qm destroy continues past disk-removal failures.

Working around the LXC case (when storage is offline and you need the container gone)

Three options, in order of preference:

Option 1: Manual conf removal (used 2026-05-31 for LXC 500)

rm /etc/pve/lxc/<id>.conf

Equivalent outcome to what qm destroy --purge does for VMs on the same offline storage: container conf removed from Proxmox cluster state, disk file orphaned on the storage. After this, pct list no longer shows the container.

Caveats: - Bypasses Proxmox's purge-from-related-configs step. If the LXC was referenced in backup jobs, replication jobs, HA, etc., those references will dangle. (Usually fine for the obsolete-cleanup scenarios where the container hasn't been touched in months.) - No way to "undo" — make sure you have an inventory snapshot first if there's any chance of needing the conf later.

Option 2: Edit rootfs out of conf, then destroy

pct set <id> --delete rootfs   # removes the storage reference
pct destroy <id> --purge

Two steps. Works because pct set --delete <key> only edits the conf without touching storage. Then pct destroy has no storage references to fail on.

Not validated on this box yet — option 1 was used. If you try option 2, note whether pct set --delete rootfs itself succeeds when storage is offline (might also abort hard, in which case use option 1 anyway).

Option 3: Wait for storage to return

Cleanest end state — pct destroy --purge will work normally once the underlying storage is reachable, and the disk file is removed in the same operation. No orphans, no manual cleanup.

Only viable if the storage is expected to come back. If it's gone for good, option 1 or 2.

Why this asymmetry exists (speculation)

LXC containers are running directly on the host kernel; the rootfs is a filesystem the host must mount during pct start. Proxmox's pct codepath is more conservative because half-destroyed container state (conf gone but mount points lingering, or vice versa) can leave the host in worse shape than half-destroyed VM state. So pct destroy bails out the moment it can't fully reach the storage.

VMs are isolated by the qemu process — half-destroyed state mostly only affects what's in qm list, with no direct kernel-side consequences. qm destroy is therefore more permissive.

This rationale isn't documented; it's just the consistent behaviour observed.

  • D:\PVE\SESSION-LOG.md 2026-05-31 late evening Session 6 — the cleanup operation that surfaced this.
  • D:\PVE\pre-destruction-inventory-20260531-205954.txt — what was on the host before cleanup.
  • D:\PVE\orphaned-fast-disks-20260531-212124.txt — per-file orphan inventory after cleanup.