Kevin AdamsandClaude Opus 5.5 71feee8ab2 docs: publish the real v3→v4 upgrade path (#293) ...

v4.0.0/4.0.1 shipped on the v4 track, but upgrade-paths.md still said v3→v4
was "future" with TBDs, and the README, getting-started and migrating-from-v2
docs still installed from v3. A v3 operator had no supported procedure.

v3→v4 is an in-place apt upgrade:
- storage.cfg is unchanged and the transport is auto-detected per host
- only the PVE daemons restart, not running VMs
- the multipath component moves along with the track

Added pre-checks (PVE 9, leftover v2 storages, orphan volumes, API key),
verification and rollback steps, and the v2→v4 ordering.

Also fixed the PVE 8 guidance. v3.1+ already needs PVE 9 (ADR-009), so
"stay on v3" isn't enough: on PVE 8 only 3.0.0-1 loads, and it has to be
pinned. CLAUDE.md had the API key field name wrong (truenas_api_token).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-13 10:01:18 -04:00

..

architecture.md

docs: document v4.0.1 multipath re-verification through the real daemon

2026-09-01 23:59:51 -04:00

getting-started.md

docs: publish the real v3→v4 upgrade path (#293)

2026-10-13 10:01:18 -04:00

migrating-from-v2.md

docs: publish the real v3→v4 upgrade path (#293)

2026-10-13 10:01:18 -04:00

migration-advanced.md

docs: document multipath and fix stale v3.0-beta-era content

2026-08-30 08:47:11 -04:00

migration-troubleshooting.md

fix: let path() return a placeholder for extent-less zvols (#292)

2026-10-12 11:57:43 -04:00

upgrade-paths.md

docs: publish the real v3→v4 upgrade path (#293)

2026-10-13 10:01:18 -04:00