Migrate Longhorn volumes to V2 and retire node iSCSI #5582

🤖 Generated by the Agentic Engineer

User story

As the platform owner, I want Longhorn storage to use Data Engine V2 and every platform node to run without iSCSI, so storage can benefit from the newer data path and avoid maintaining the legacy host dependency.

Current delivery priority

Maintainer direction on 2026-11-02: move the platform's production volumes to released V2 now, using necessary temporary platform workarounds, without waiting for upstream fixes. The migration is delivered only when the actual volumes run on V2 and application, replica-health and recovery checks pass. Source changes and queued PRs do not meet that outcome.

Retain the real iSCSI host package temporarily for Longhorn 1.13.0 compatibility. Its later removal and the upstream release dependencies are tracked on our side in #5781; they do not block the volume migration. #5782 checks whether unused temporary storage can provide a route that keeps the original data-bearing workers intact during cutover. The currently reviewed preparation route remains available until an alternative has its own proofs.

Delivery plan

1. Verify V2 requirements against the installed Longhorn and Talos versions; inventory volumes, consumers, retained recovery claims, backup coverage and raw-disk capacity.
2. Prepare raw block storage and V2 node prerequisites through the owning declarative configuration and protected deployment path. Preserve current V1 service until its data is migrated.
3. Prove a V2 canary, including write/read persistence, reattachment, replica recovery and backup/restore. Capture a comparable baseline and benchmark without promising a fixed performance multiplier.
4. Migrate each existing workload and retained volume with verified rollback data and application checks. Preserve database consistency and required redundancy.
5. Set V2 provisioning defaults, disable V1 after its final consumer is retired, remove iSCSI from the node image and future-node configuration, and roll all node classes safely.
6. Verify application health, backups, live node extensions and absence of V1 volumes and iSCSI sessions; update affected repository documentation and templates.

Acceptance criteria

• Every existing Longhorn volume and retained recovery claim is accounted for and migrated or explicitly retired with preserved data and evidence.
• All production Longhorn volumes run on V2 with the required replica health; persistence, reattachment and backup/restore are verified.
• Existing applications and databases pass their functional checks after migration.
• V2 is the provisioning default and V1 is disabled.
• No current platform node has the iSCSI extension or an active iSCSI session; all future-node definitions omit it.
• Configuration owners, reusable templates, recovery procedures and validation cover the final deployment.
• Comparable benchmark results are reported accurately; an advertised upper bound is not treated as a measured result.

Safety and scope

Changing a StorageClass does not convert existing volumes. V1 filesystem disks cannot be relabeled as V2 block disks. Disk preparation, engine activation, data migration and host dependency removal are separate rollout stages; completion requires the observed final state, not a configuration-only change.

Requested directly by the maintainer on 2026-10-29. The maintainer approved rolling local disk rebuilds using temporary migration capacity. Disk-changing operations remain gated on the reviewed preparation and recovery proofs.

Longhorn 1.13.0 currently checks iscsiadm during startup and pre-upgrade. The V2-only proposal and implementation contributions are not released support; #5781 carries their status and the eventual all-node retirement acceptance. No additional upstream CI or hygiene work is part of this migration.