Documentation survey

This is unreleased documentation for SUSE® Storage 1.10 (Dev).

Important Notes

Please see here for the full release notes.

Removal

longhorn.io/v1beta1 API

The v1beta1 Longhorn API version was removed in SUSE Storage v1.10.0.

For more details, see Issue #10249.

replica.status.evictionRequested field

The deprecated replica.status.evictionRequested field has been removed.

For more details, see Issue #7022.

General

Kubernetes Version Requirement

Due to the upgrade of the CSI external snapshotter to v8.2.0, you must be running Kubernetes v1.25 or later to upgrade to SUSE Storage v1.8.0 or a newer version.

CRD Upgrade Validation

During an upgrade, a new Longhorn manager might start before the Custom Resource Definitions (CRDs) are applied. This sequence ensures the controller doesn’t process objects with deprecated data or fields. However, if the CRD hasn’t yet been applied, the Longhorn manager can fail during the initial upgrade phase.

If the Longhorn Manager crashes during the upgrade, check the logs to determine if the CRD not being applied is the cause of the failure. In such cases, the logs might contain error messages similar to the following:

time="2025-03-27T06:59:55Z" level=fatal msg="Error starting manager: upgrade resources failed: BackingImage in version \"v1beta2\" cannot be handled as a BackingImage: strict decoding error: unknown field \"spec.diskFileSpecMap\", unknown field \"spec.diskSelector\", unknown field \"spec.minNumberOfCopies\", unknown field \"spec.nodeSelector\", unknown field \"spec.secret\", unknown field \"spec.secretNamespace\"" func=main.main.DaemonCmd.func3 file="daemon.go:94"

Upgrade Check Events

When you upgrade with Helm or the Rancher App Marketplace, SUSE Storage performs pre-upgrade checks. If a check fails, the upgrade stops and the reason for the failure is recorded in an event.

For more details, see Upgrading Longhorn Manager.

Manual Checks Before Upgrade

Automated pre-upgrade checks does not cover all scenarios. A manual check is recommended using kubectl or the SUSE Storage UI.

  • Ensure all V2 Data Engine volumes are detached and replicas are stopped. The V2 engine does not support live upgrades.

  • Avoid upgrading when volumes are Faulted. Unusable replicas may be deleted, causing permanent data loss if no backups exist.

  • Avoid upgrading if a failed BackingImage exists. For more information, see Backing Image for details.

  • Create a Longhorn System Backup upgrading is recommended to ensure recoverability.

Consolidated SUSE Storage Settings

Settings have been consolidated for easier management across V1 and V2 Data Engines. Each setting now uses one of these formats:

  • Single value for all supported data engines:

    • Format: Non-JSON string (for example, 1024)

    • This value applies to all supported data engines and must be the same across them. Data engine-specific values are not allowed.

  • Data engine-specific values for V1 and V2 data engines:

    • Format: JSON object (for example, {"v1": "value1", "v2": "value2"})

    • This allows you to specify different values for the V1 and V2 data engines.

  • Data engine-specific values for V1 data engine only:

    • Format: JSON object with a v1 key only (for example, {"v1": "value1"})

    • This allows you to configure only the V1 data engine, and it does not affect the V2 data engine.

  • Data engine-specific values for V2 data engine only:

    • Format: JSON object with a v2 key only (for example, {"v2": "value1"})

    • This allows you to configure only the V2 data engine, and it does not affect the V1 data engine.

For more information, see the SUSE Storage Settings.

System Info Category in Setting

A new System Info category has been added to show cluster-level information more clearly.

For more details, see Issue #11656.

Configurable Backup Block Size

The SUSE Storage UI now display a summary of attachment tickets on each volume overview page for improved visibility into volume state.

For more details, see Issue #11400 and Issue #11400.

Scheduling

Pod Scheduling with CSIStorageCapacity

SUSE Storage now supports Kubernetes CSIStorageCapacity, which enables the scheduler to verify node storage before it schedules pods that use StorageClasses with WaitForFirstConsumer. This reduces scheduling errors and and improves reliability.

For more details, see Issue #10685.

Performance

Configurable Backup Block Size

Backup block size can now be configured when you create a volume, starting in SUSE Storage v1.10.0. This allows you to optimize for performance, efficiency, and cost.

For more information, see Create Longhorn Volumes.

Profiling Support for Backup Sync Agent

The backup sync agent has a pprof server for profiling runtime resource usage during backup sync operations.

For more information, see Profiling.

Resilience

Configurable Liveness Probe for Instance Manager

You can now configure the instance-manager pod liveness probes. This allows the system to better distinguish between temporary delays and actual failures, which helps reduce unnecessary restarts and improves overall cluster stability.

For more information, see SUSE Storage Settings.

Backing Image Manager CR Naming

Backing Image Manager CRs now use a compact, collision-resistant naming format to reduce the risk of conflicts.

For more details, see Issue #11455.

Security

Refined RBAC Permissions

RBAC permissions have been refined to minimize privileges and improve cluster security.

For more details, see Issue #11345.

V1 Data Engine

IPv6 Support

V1 volumes now support single-stack IPv6 Kubernetes clusters.

Dual-stack Kubernetes clusters and V2 volumes are not supported in this release.

For more details, see Issue #2259.

V2 Data Engine

SUSE Storage System Upgrade

Live upgrades of V2 volumes are not supported. Before you upgrade, make sure all V2 volumes are detached.

New Introduced Functionalities since SUSE Storage v1.10.0

V2 Data Engine Without Hugepage Support

The V2 Data Engine can run without Hugepages by setting `data-engine-hugepage-enabled to `{"v2":"false"}. This reduces memory pressure on low-spec nodes and increases deployment flexibility. The performance may be lower compared to running with Hugepage.

V2 Data Engine Interrupt Mode Support

Interrupt mode has been added to the V2 Data Engine to help reduce CPU usage. This feature is especially beneficial for clusters with idle or low I/O workloads, where conserving CPU resources is more important than minimizing latency.

While interrupt mode lowers CPU consumption, it may introduce slightly higher I/O latency compared to polling mode. In addition, the current implementation uses a hybrid approach, which still incurs a minimal, constant CPU load even when interrupts are enabled.

For more information, see Interrupt Mode.

V2 Data Engine Replica Rebuild QoS

Provides Quality of Service (QoS) control for V2 volume replica rebuilds. You can configure bandwidth limits globally or per volume to prevent storage throughput overload on source and destination nodes.

For more information, see Replica Rebuild QoS.

V2 Data Engine Volume Expansion

SUSE Storage now supports volume expansion for V2 Data Engine volumes. Users can expand the volume through the UI or by modifying the PVC manifest.

For more information, see Volume Expansion.