RATATOSKRATATOSK
Sign in

Releases

AI-analyzed release notes for CNCF graduated and incubating projects.

Project: LonghornClear ×

Longhorn

Storage & DataJul 1, 2026

Longhorn v1.11.3 is a bugfix rollup addressing over a dozen stability issues across volume operations, backups, and instance management. One upgrade prerequisite applies: the CSI external provisioner is now v6.3.0, requiring Kubernetes v1.34 or later when upgrading from v1.10.x or v1.11.0.

  • breakingKubernetes v1.34+ required when upgrading from v1.10.x or v1.11.0

    The bundled CSI external provisioner is bumped to v6.3.0, which requires Kubernetes v1.34 or later. If your cluster runs an older Kubernetes version and you are upgrading from Longhorn v1.10.x or v1.11.0, bring Kubernetes to v1.34+ first before applying this upgrade.

Key changes (7)
  • CSI external provisioner bumped to v6.3.0: clusters must run Kubernetes v1.34+ before upgrading from v1.10.x or v1.11.0
  • Fixed iscsid restarts leaving V1 volumes inoperable, blocking PVC resize and other volume operations
  • Fixed nil pointer dereference panic in longhorn-instance-manager during replica rebuild
  • Fixed deadlock causing recurring trim jobs to fail, and separate fixes for volume expansion getting stuck
  • Fixed migration engine being deleted while target node was still transitioning to ready
  • Fixed backup uploads to S3 failing on NetApp appliances, and fixed System Backup RecurringJob incorrectly pruning the newest CR
  • Fixed longhorn-manager panic in BackupController during backup deletion, plus HTTP response body leaks in support bundle and webhook polling; reduced webhook TLS Secret contention at scale
Source

Longhorn

Storage & DataJun 2, 2026

Longhorn v1.12.0 promotes the V2 Data Engine to GA, ships dual-stack/IPv6 support, and fixes critical instance-manager panics and replica scheduling bugs that caused cascading volume failures.

  • breakingMigrate V2 backing image volumes before upgrading

    Any V2 volume created from a backing image cannot be upgraded in-place. Before upgrading to v1.12.0, back up each affected volume, delete it, and restore from backup — the restored volume has no backing image dependency. Skipping this step will cause attach failures post-upgrade. Use CDI for future VM disk image imports.

  • breakingDetach V2 volumes before patch-level upgrades

    V2 volumes do not support live upgrades between v1.12.x patch releases. Plan maintenance windows to detach all V2 volumes before applying patch upgrades. Live upgrade across minor versions (v1.12 to v1.13) is planned but not yet available.

  • breakingEncrypted migratable volumes need engine image upgrade before live migration

    The LUKS2 header pre-allocation fix for encrypted volumes introduces a constraint: live migration of encrypted volumes requires engine image CLI API version 12 or later. Upgrade the engine image to v1.12.0+ before attempting live migration; otherwise migration will fail.

  • enhancementReview SPDK CPU allocation on existing V2 deployments

    The default CPU mask now uses 2 cores instead of 1. For clusters already running V2 volumes with a manually set single-core mask, consider increasing it — single-core configs under heavy I/O cause RPC starvation and operational instability. On ARM64 with NVMe-backed node disks, avoid multi-core SPDK configs for now and use AIO-backed disks until the stuck I/O bug is resolved.

  • enhancementEnable dual-stack networking — but verify node IP family ordering first

    Dual-stack Kubernetes clusters are now supported, but only when all nodes have IP families configured in the same order (all IPv4-first or all IPv6-first). Audit your node network configs before enabling. Mixed ordering causes replica-to-engine connectivity failures with no obvious error surface.

Key changes (6)
  • V2 Data Engine reaches GA — but live upgrades between v1.12 patch releases require volume detach first; live upgrade support comes in v1.13
  • V2 Backing Images removed; migrate by backup/restore via CDI before upgrading or face volume attach failures
  • Default SPDK CPU mask changed from 1 core (0x1) to 2 cores (0x3) to prevent RPC starvation under heavy I/O
  • Topology-aware PV provisioning added via csi-allowed-topology-keys setting and strictTopology StorageClass parameter
  • CSIStorageCapacity bug fixed — compute-only nodes no longer report zero capacity and block WaitForFirstConsumer scheduling
  • Instance-manager panic during replica rebuild storms fixed, eliminating cascading volume detachments across PVCs
Source

Longhorn

Storage & DataMay 5, 2026

Longhorn v1.11.2 is a stability-focused patch fixing CSI scheduling breakage in compute/storage split architectures, infinite replica scheduling loops, and memory bloat in longhorn-manager.

  • breakingFix CSI scheduling in compute/storage split clusters — action required

    If you run a dedicated compute/storage node architecture and use WaitForFirstConsumer PVCs, your pods may have been stuck pending due to compute nodes reporting 0 CSI capacity. Upgrade to v1.11.2 and configure the new CSIStorageCapacity setting to prevent capacity reporting on non-storage nodes. Check your Longhorn settings after upgrade and validate that pending PVCs now schedule correctly.

  • breakingReplica Auto-Balance infinite loop — upgrade if you use Auto-Balance

    A bug caused Replica Auto-Balance to enter an infinite scheduling loop, which wastes CPU and can destabilize volume operations. If Auto-Balance is enabled in your cluster, this is a strong reason to prioritize this patch. No config change needed after upgrade — the fix is in the reconciliation logic.

  • enhancementMemory savings in longhorn-manager — relevant for large clusters

    Informer caching for longhorn-manager has been optimized to reduce cluster-wide memory consumption. In large clusters with many nodes and volumes, this can meaningfully reduce the manager pod's footprint. No action required beyond upgrading, but worth monitoring memory usage before and after to quantify the improvement in your environment.

Key changes (5)
  • New setting to control CSIStorageCapacity reporting — fixes WaitForFirstConsumer scheduling failures on compute nodes without Longhorn disks
  • Replica Auto-Balance infinite scheduling loop bug fixed, which could cause runaway reconciliation
  • Replica rebuild progress capped at 100% — cosmetic but caused confusion under flaky network conditions
  • longhorn-manager memory reduced via optimized cluster-wide informer caching
  • Node exhaustion from backup inspect buildup under NFS latency conditions resolved
Source

Longhorn

Storage & DataMar 13, 2026

Longhorn v1.11.1 delivers critical bug fixes including a major memory leak in instance manager pods and backup failures with S3-compatible storage, making it an urgent upgrade for v1.11.0 users.

  • securityBackup restore functionality compromised

    S3-compatible backup targets (Storj, GCS) were failing due to AWS SDK v2 authorization issues. Test your backup and restore workflows after upgrading, especially if using non-AWS S3 endpoints. Verify large backup transfers complete successfully.

  • breakingUrgent upgrade required for v1.11.0 users

    Users running v1.11.0 experiencing high memory usage in instance manager pods must upgrade immediately. The memory leak can cause cluster instability and pod evictions. Plan upgrade maintenance window and monitor memory usage during rollout.

  • enhancementImproved scheduling with topology awareness

    New CSI topology-aware nodeAffinity controls provide better volume placement. Review your storage class configurations to leverage allowedTopologies and strictTopology settings for multi-zone deployments and specific node scheduling requirements.

Key changes (5)
  • Fixed critical memory leak in longhorn-instance-manager pods caused by proxy connection leaks
  • Resolved AWS SDK v2 compatibility issues causing backup failures to S3-compatible storage like Storj and GCS
  • Enhanced V2 Data Engine with improved fast replica rebuild and clone functionality
  • Added CSI topology-aware PV nodeAffinity control for better scheduling
  • Fixed storage double-counting that caused scheduling failures when multiple replicas exist on same node
Source