Important Notes

V2 linked-clone volumes created in v1.12.0 or earlier are marked as legacy and deprecated starting in v1.12.1. The new linked-clone architecture introduced in #12552 is not compatible with the legacy design.

After upgrading to v1.12.1, legacy linked-clone volumes cannot be operated on except for detachment and deletion.

To replace, create new linked-clone volumes from the same source volumes that back the legacy ones. If a legacy volume exists, its source volume is guaranteed to still be present, so you can create a replacement linked clone directly - no data copy is required.

For more information, see #12552.

The V2 Data Engine became generally available in SUSE Storage v1.12.0. This milestone reflects improvements in stability, networking support, and feature maturity, making V2 volumes suitable for production use in supported environments.

SUSE Storage v1.13.0 builds on that GA foundation with live upgrade support for V2 volumes and refined V2 linked-clone feature. It also continues to improve V2 volume stability.

For a summary of the current V1 and V2 behavior differences and feature parity, see V1 and V2 Volume Behavior and Feature Parity.

For more information, see #6229.

Interrupt mode for the V2 Data Engine, available since v1.10.0, no longer polls for I/O completions in SUSE Storage v1.13.0. The kernel wakes the V2 Data Engine when I/O completes, so idle instance-manager pods use very little CPU. Latency can be slightly higher than in polling mode under sustained heavy I/O.

Polling mode remains the default. To enable interrupt mode, set data-engine-interrupt-mode-enabled to {"v2":"true"}. The setting applies to all V2 volumes and can be changed only when no V2 volumes are attached.

For more information, see:

When assigning CPU cores to the V2 Data Engine, ensure that the V2 instance-manager pod has enough guaranteed CPU resources to cover the assigned cores. This provides dedicated CPU availability for SPDK reactors, prevents CPU contention, and helps maintain predictable performance and V2 Data Engine stability.

You can verify that the guaranteed CPU resources match the CPU cores specified by data-engine-cpu-mask or data-engine-number-of-cpu-cores. For more details, see Guaranteed Instance Manager CPU, Data Engine CPU Mask, and Data Engine Number of CPU Cores.

Backups of V2 linked-clone volumes now record the source volume and the snapshot the clone was created from. A restore fails if the source volume or that snapshot no longer exists.

Previously, the restore succeeded and produced a corrupted volume.

For more information, see #13714 and CSI Volume Clone.

When cloning a volume with dataLocality: strict-local, SUSE Storage now attaches the clone for its data copy on a node that matches the volume’s nodeSelector and diskSelector.

Previously, this node was chosen without checking the selectors, and strict-local pinned the clone’s single replica to it. If the node did not match the selectors, the replica could not be scheduled. The clone then failed with hard affinity cannot be satisfied.

For more information, see #12792.

SUSE Storage now allows you to clean up a SUSE Storage node after the Kubernetes node was deleted without evicting it first. You can disable scheduling on the node, remove its remaining replicas and engines, and then delete it.

Previously, the SUSE Storage admission webhook rejected the request to disable scheduling because the disk status of a deleted node can no longer be synced. Because a schedulable node cannot be deleted, the SUSE Storage node remained in the cluster until the webhook was disabled.

Evicting a node before deleting it from the cluster is still the recommended procedure.

For more information, see #13494 and Graceful Node Removal.

The backing image manager now copies backing images over the cluster’s IP family and the storage network, like the other SUSE Storage components.

Previously, it always used IPv4. On IPv6 single-stack and IPv6-first dual-stack clusters, a backing image could not be copied to other nodes, so it stayed at one copy.

For more information, see #13864 and Backing Image.

Because the CSI external provisioner is upgraded to v6.3.0, all clusters must be running Kubernetes v1.34 or later before upgrading to SUSE Storage v1.13.0.

Automated pre-upgrade checks do not cover all scenarios. Manual checks via kubectl or the UI are recommended:

SUSE Storage v1.13.0 adds the volumeTopology StorageClass parameter to keep a volume’s replicas in the zone or region where it was provisioned. Previously, zone labels only spread replicas apart, so a rebuild could place a replica in a different zone from the workload.

If the chosen zone or region has no capacity, scheduling waits rather than falling back to another one. Clusters without topology labels are unaffected. A StorageClass with volumeTopology: zonal and replicaZoneSoftAntiAffinity: disabled is rejected at provisioning time.

For more information, see #13493 and Topology-Aware Provisioning.

SUSE Storage v1.13.0 adds a scheduler extender that lets kube-scheduler check actual SUSE Storage disk capacity when placing pods. Without it, kube-scheduler relies on CSIStorageCapacity objects, which have three limitations:

The extender reads SUSE Storage node and disk state directly. It also pins a restarted pod to the node that already holds all of its replicas, which makes it most useful for volumes with best-effort data locality.

The extender runs inside longhorn-manager under leader election, so there is no extra component to deploy. It requires a change to the kube-scheduler configuration, which is not possible on managed Kubernetes offerings such as GKE and EKS.

For more information, see #12591.

SUSE Storage v1.13.0 moves the cluster-wide pod and PV controllers out of the longhorn-manager DaemonSet into a new longhorn-global-manager Deployment. Previously, every longhorn-manager pod watched every pod in the cluster, so kube-apiserver load and longhorn-manager memory grew with the number of nodes and pods. Now one elected leader runs these controllers, and longhorn-manager watches only the longhorn-system namespace.

The Deployment is created on install and upgrade, with three replicas by default (longhornGlobalManager.replicas): one leader and two standby replicas ready to take over. Before upgrading, make sure at least one of its pods can be scheduled. See [Upgrading Longhorn Manager](../deploy/upgrade/longhorn-manager).

For more information, see:

SUSE Storage v1.13.0 can snapshot a set of volumes as one group with a single request. You can create snapshot groups from the SUSE Storage UI, with kubectl, or by creating Kubernetes VolumeGroupSnapshot objects through CSI. The CSI path also supports group backups.

The UI and kubectl paths work out of the box. The CSI path is disabled by default: it requires the VolumeGroupSnapshot CRDs, the CSIVolumeGroupSnapshot feature gate on the snapshot-controller, and a SUSE Storage toggle. For the setup steps, see Enable CSI Volume Group Snapshot Support.

For more information, see:

SUSE Storage v1.13.0 adds an age-based retention policy for snapshot, backup, and system backup recurring jobs. Set retentionPolicy to age-based and retainAge to a duration such as 720h. On each run, the job deletes snapshots or backups older than retainAge, regardless of how many exist or how often the job runs. Supported units are s, m, and h, so write 24h for one day.

The count-based policy remains the default, and existing recurring jobs keep it after the upgrade, so their behavior does not change. The two policies do not combine: count-based ignores retainAge, and age-based ignores retain.

For more information, see #12060.

SUSE Storage v1.12.1 enables ingress NetworkPolicy resources for internal component endpoints and RPCs by default, including the instance-manager gRPC endpoint used for engine control. The policies take effect only when the CNI plugin enforces NetworkPolicy. Otherwise, the resources are created but have no effect. For details, see Network Policy.

SUSE Storage v1.12.2 resolves the CNI compatibility issues found in v1.12.1 by providing two Helm values to manage the affected traffic paths:

For the Kubernetes distribution and CNI combinations validated with networkPolicies.restrictInternalTraffic enabled, see CNI Plugin Compatibility. If your combination is not listed, test the policies in a non-production environment before upgrading.

For Helm installations, opt out by explicitly setting networkPolicies.restrictInternalTraffic=false in the values file or passing --set networkPolicies.restrictInternalTraffic=false when running or retrying helm upgrade. Use --reuse-values with helm upgrade when appropriate to retain previous release settings. Keep this separate from networkPolicies.enabled, which controls only the UI frontend policy. See the Helm upgrade documentation for command behavior.

After a successful upgrade with networkPolicies.restrictInternalTraffic=false, the six internal NetworkPolicy templates render nothing (they are excluded from the output), and policies owned by the Helm release are removed. Preview the rendered output with helm upgrade --dry-run or helm template; do not add --reuse-values to helm template. If installed, helm diff can optionally compare the changes.

For manifest installations, delete only these six internal NetworkPolicy resources:

These resources are defined in longhorn.yaml and longhorn-okd.yaml. Do not use kubectl delete -f on an entire SUSE Storage manifest or delete the SUSE Storage installation. Applying either unmodified manifest later recreates the policies.

If an upgrade fails because these policies block required traffic, set networkPolicies.restrictInternalTraffic=false and retry the same upgrade.

For more information, see #13438.