felhom.eu/documentation/audits/os-guest-lane-2026-10-04/partA

Part A — the snapshot undo (R-837), demo-hp 9201, 2026-10-04 ~10:30 CEST

Result: a snapshot of a customer guest is NOT possible. The automatic undo is not built (the brief's stop rule).

• Thin pool before: data 61.90 %, metadata 2.69 % (A1-snapshot.txt). After: unchanged (A2-after.txt) — nothing was created.
• The agent's token has the rights: role FelhomAgentGuest on /pool/felhom holds VM.Snapshot and VM.Snapshot.Rollback. Called AS THE TOKEN (POST /nodes/demo-hp/lxc/9201/snapshot, http 200): the task ends snapshot feature is not available in 0.1 s. As root, pct snapshot 9201 r837root: the same.
• Why, from the PVE source: PVE/AbstractConfig.pm:755-757 dies with that message when has_feature('snapshot', …, $snapname eq 'vzdump') fails; PVE/LXC/Config.pm:97-110 checks EVERY mount point and skips non-backup ones ONLY when that last flag is set — i.e. only for the backup's own snapshot named vzdump. A customer guest always carries two host-path binds (mp8 /mnt/felhom-drives, mp9 …/bootstrap), which have no snapshot feature. So: rootfs and mp0 are LVM-thin and could snapshot; the guest cannot.
• The nightly whole-guest backup still works in snapshot mode (create storage snapshot 'vzdump', 04:34:55).
• Rejected, not tried: naming a snapshot vzdump to pass the check — the name is the backup's own and a collision would break the night's backup; and taking raw LVM thin snapshots of rootfs + mp0 behind PVE's back (a new mechanism nobody has measured — a STATUS decision, not a session improvisation).
• Steps 2–3 (apply by hand, roll back) were not run: there is nothing to roll back to. 9201 is brought current by the product's own OS leg in Part G.