New Features in 5.4.0

  • Updated on Jan 31, 2026
  • Published on Jan 26, 2026
  • 25 minute(s) read
Prev Next

L3 Numbered BGP

VAST cluster L3 networking capabilities have been expanded by adding support for Numbered BGP, which relies on peer IP assignments to establish peer-to-peer relationships.

In VAST Web UI, BGP settings (Network Access -> BGP Configurations -> choose to create or edit a BGP configuration) have been updated to let you:

  • Select numbered or unnumbered BGP.

  • In the new VIPs tab:

    • Enter a range of virtual IP addresses to be used for peer-to-peer connections.

    • Set whether the CNodes/switch ports are assigned Even or Odd IP addresses from the specified range.

In addition, the BGP Connections page in VAST Web UI has been renamed to BGP Peering and includes indication of the source IP and peer IP for each BGP connection.

The following limitation applies:

  • ORION-266297: When using numbered BGP, each CNode can only be involved in  one BGP configuration. To learn which CNodes are currently used in which BGP configurations, use the Network Access -> Virtual IP Pools page that displays CNodes and BGP Configurations for each virtual IP pool.

Support for Kerberos Providers other than Active Directory Kerberos

VAST Cluster 5.4 expands Kerberos support so that VAST cluster tenants can use MIT Kerberos as an authentication provider.

The following user controls have been added for this purpose:

  • In VAST Web UI, the User Management -> Providers page includes tabs for all providers that you can associate with a VAST cluster tenant. To create a new Kerberos provider, open the Add New Provider dropdown on the top right of the page and select Kerberos.

    After you've added a Kerberos provider, the  User Management -> Providers page will include a new tab named Kerberos designed to let you view and manage Kerberos providers.

  • In VAST CLI:

    • Use the kerberos * commands to create and manage Kerberos providers.

    • To associate a Kerberos provider with the tenant, specify the --krb-provider-id option on the tenant create and tenant modify commands.

    • To remove an association between a Kerberos provider and a tenant, specify the --detach-krb-provider option on the tenant modify command.

The following rules and limitations apply:

  • MIT Kerberos providers are used for NFSv4 only.

  • A tenant can be associated with a single Kerberos provider only.

  • Up to eight Kerberos providers can be defined on a VAST cluster.

  • Kerberos principals used to authenticate to the VAST cluster must exists as users in an LDAP provider or in a local provider associated with the same tenant as the Kerberos provider. Otherwise, they are squashed to the nfsnobody user.

The following known issue may be encountered:

  • ORION-265720: VAST CLI auto-completion does not include the  --detach-krb-provider option on the tenant modify command.

NFSv4 File Delegations

The VAST NFSv4 server can optionally grant a read or write delegation to the client opening a file.

  • If the server grants a read delegation, the client can cache the data and read from the cache, while the server assures that no other client can write to the file for the duration of the delegation.

  • If the server grants a write delegation, the client can cache data and metadata, and perform both read and write operations on it, while the server assures that no other client can write to the file or read from it for the duration of the delegation.

Use of file delegations may significantly reduce the amount of client-server communication for the files being delegated, boosting VAST cluster performance for specific types of workloads, such as cloning or getting status information of a GitHub repository, running SQLite queries, compilation tasks, or extracting data from very large ZIP or TAR archives.

By default, on new installations, NFSv4 file delegations are enabled for both read and write operations. In upgraded environments, the pre-existing tenants have NFSv4 file delegations disabled.

The following user controls have been added for this feature:

  • In VAST Web UI:

    • The Enable read delegations and Enable write delegations toggles, and also the Enable Unrequested NFSv4 File Delegations by Default in tenant settings (Element Store -> Tenants -> choose to create or edit a tenant -> Advanced Protocol Settings tag)

    • The page for view's locks and open handles has been expanded to let you list and manage existing NFSv4 delegations per view (Element Store -> Views -> right-click a view and select Locks -> File Byte-range locks and open handles and file delegations).

  • In VAST CLI:

    • The --allowed-delegations, --enable-grant-unrequested-delegations-by-default and --disable-grant-unrequested-delegations-by-default options on the tenant create and tenant modify commands

    • The tenant nfs4-delegs-list and tenant nfs4-delegs-remove commands

The following requirements and limitations apply when using NFSv4 file delegations:

  • The NFSv4 protocol requires Network Time Protocol (NTP) to be configured on both the VAST cluster and the client. While VAST does not enforce this requirement, the absence of proper time synchronization may, in rare cases, result in unexpected behavior.

  • The client must have an NFSv4 backchannel connection.

  • NFSv4 delegations are not supported with RDMA.

  • Using NFSv4 file delegations on views for which other protocols are enabled, may result in unexpected behavior.

  • Before making a path read-only by using the /folders/read_only endpoint of VAST REST API, ensure that NFSv4 delegations are disabled or returned. Otherwise, unexpected behavior may be encountered.

  • Restoring a snapshot on a tenant that have NFSv4 delegations enabled, may cause unexpected behavior with regard to delegated files. It is recommended to revoke existing delegations before restoring a snapshot.

  • VAST Cluster recalls granted NFSv4 delegations when a failover process is started.

  • In some cases when there is very high NFSv4 callback load per cluster or per client, VAST Cluster might start recalling or revoking NFSv4 delegations due to callback request timeouts.

  • NFSv4 delegations require mounting the client at least as NFS version 4.1. It is recommended to mount as NFS version 4.2 for additional performance improvements. Linux kernels 6.11+ on a client provide more performance advantages (RFC9754), which get backported to older kernels through VAST-NFS.NFS Features for Enhanced Performance

  • If you are using VAST-NFS, note that NFSv4 delegations are supported with VAST-NFS 4.0.32 and later. VAST-NFS 4.5 includes enhancements related to support of NFSv4 delegations.NFS Features for Enhanced Performance

  • SUSE Linux Enterprise Server 12.x and CentOS 7.x clients are not supported with NFSv4 delegations enabled.

Support for SMB Encryption

VAST Cluster 5.4 supports SMB 3.0 encryption, which helps protect in-flight data on non-secure networks.

By default, SMB encryption is disabled. You can enable it and select an encryption policy per tenant:

  • Available - Encryption is used only for SMB clients which have requested it explicitly. For clients that do not support encryption, access is allowed but no encryption is used.

  • Desired - The cluster uses encryption for any SMB client that supports encryption. For clients that do not support encryption, access is allowed but no encryption is used.

  • Required - SMB clients that do not support encryption are denied access.

If the tenant has SMB encryption enabled with one of the encryption policies set, you can override the tenant's setting by choosing a different encryption policy for a view.

A view cannot have a less strict encryption policy compared to that of the tenant. For example, if the tenant has Desired, the view can have Required but not Available.

An access denied error is returned if the cluster configuration stipulates use of encryption but the client does not use SMB 3.0, does not support encryption, or sends a non-encrypted packet.

Note

Enabling SMB encryption may result in up to 15% performance degradation compared to SMB signing.

To configure SMB encryption for a tenant:

  • In VAST Web UI, go to the Advanced Protocol Settings tab in tenant settings (Element Store -> Tenants -> choose to create or edit a tenant) and in the SMB Encryption pane, toggle the Enable encryption option on and select an encryption policy.

  • In VAST CLI, run the tenant create or tenant modify command with the --smb-encryption-state option specified.

To configure SMB encryption for a view:

  • In VAST Web UI, go to the SMB -> Encryption tab in view settings (Element Store -> Views -> choose to create or edit a view) and in the Set Activation Policy pane, select an encryption policy.

  • In VAST CLI, run the view create or view modify command with the --smb-encryption-state option specified.

Note

The view must have the SMB protocol enabled.

S3 Server-Side Encryption with Customer-Provided Keys (SSE-C)

VAST Cluster can perform server-side encryption (SSE) of S3 data at rest with the encryption keys provided by the client (SSE-C).

With SSE-C, the client provides and manages an encryption key used to encrypt the S3 objects at their destination. The cluster holds the key only for the time needed to handle the request and does not store it persistently. When accessing an encrypted object, the client is expected to provide the same encryption key as the one used to encrypt the object.

The following operations may involve SSE-C encryption:

  • GetObject

  • HeadObject

  • PutObject

  • CreateMultipartUpload

  • UploadPart

  • CopyObject

  • CopyPart

  • UploadPartCopy

  • Presigned POST

The client is expected to use the x-amz-server-side-encryption-customer-* headers to pass an 256-bit, base64-encoded encryption key, the encryption algorithm to be used and the unencrypted key checksum with each request that requires encryption of the object at its destination. For each CreateMultipartUpload request, all the subsequent UploadPart requests must contain the same values in the headers as the CreateMultipartUpload request.

Support for S3 SSE-C is enabled by default. No manual configuration is needed.

The following rules and limitations apply:

  • If an S3 request contains an x-amz-server-side-encryption-customer-* header, it is required to use HTTPS for the request to be accepted by the cluster.

  • Only AES256 encryption algorithm is supported.

  • Objects encrypted with SSE-C cannot be accessed through other access protocols.

  • For replication environments, it is strongly recommended to avoid using SSE-C unless all of the clusters involved support SSE-C.

  • S3 SSE-C is not supported when uploading objects using chunked encoding.

The following known issue can be encountered:

  • ORION-321170: Using S3 SSE-C when uploading objects using chunked encoding may result in unexpected errors.

Kafka Authentication and Authorization

This release introduces support for Kafka-compatible authentication of users connecting to Kafka-enabled views on the VAST cluster.

The VAST cluster supports SASL plain authentication by username and password on both encrypted and non-encrypted connections.

VAST implementation of user authorization is based on identity policies rather than on Kafka ACLs. In identity policies, you can list permissions for various Kafka operations against topics, consumer groups, and the Kafka cluster.

To set up Kafka authorization and authentication:

  • In VAST Web UI, use the Authentication Methods pane in Kafka-enabled view settings (Element Store -> Views -> choose to create or edit a view -> Kafka tab)

  • In VAST CLI, run the view create or view modify command with the corresponding options specified:

    • Authentication on encrypted connections: --enable-kafka-encrypted-conn, --kafka-encrypted-auth-mechanism, --disable-kafka-encrypted-conn

    • Authentication on non-encrypted connections: --enable-kafka-unencrypted-conn,  --kafka-unencrypted-auth-mechanism, --disable-kafka-unencrypted-conn

    • Authorization: --require-kafka-authorization or --cancel-kafka-authorization

The following limitations applies:

  • Active Directory/LDAP is not supported. The user must be defined as a VAST local user.

  • Only one Kafka TLS certificate can be uploaded per VAST cluster.

Support for Kafka Config APIs

VAST Cluster 5.4 supports describeConfigs and alterConfigs Kafka APIs that let you get and update the configuration for event topics.

You can view and change the configuration parameters in VAST Web UI, CLI and via REST API.

The topic settings dialog in VAST Web UI has been expanded to include more configuration parameters, and also to support the edit mode.

Kafka Topic Compaction

VAST Cluster 5.4.0 supports Kafka topic compaction.

If compaction is enabled for a topic, any old records get deleted when there is a newer version of the record with the same key in the partition log. Compaction is performed asynchronously in the background, meaning that at some point in time, duplicate keys may exist.

To enable or disable topic compaction in VAST Web UI, use the new Compaction flag in topic settings (DataBase -> VAST Database -> navigate to the topic you need and open its properties).

Publishing S3 Notifications to VAST Event Broker

With VAST Cluster 5.4.0, you can publish events occurring in the S3 Bucket views for which S3 event notifications are configured, to one of the Kafka-enabled views on the same VAST cluster.

To do so in VAST Web UI, select the destination Kafka-enabled view in the Broker field of event notification settings (Element Store -> Views -> choose to create or edit a view -> S3 -> Bucket Notifications tab).

Data Protection Capabilities for Event Topics

The following data protection capabilities are supported for VAST Event Broker topics:

  • VAST asynchronous replication and failover

    The replicated topics are read-only at the destination peer. In case of a failover, the destination peer becomes the one hosting the topics to which events are produced.

  • Snapshots and global snapshot cloning

    A clone can be created from either local or remote snapshots.

The following rules and limitations apply:

  • The Kafka-enabled view needs to be manually created and associated with a virtual IP pool at the destination peer. The pool must have the same name as the one at the source peer.

  • Fast restore of a protected path containing a Kafka-enabled view is not allowed.

  • Consumer group offsets are not replicated.

VAST Query Engine

VAST Cluster 5.4.0 includes VAST implementation of a database query engine, the VAST Query Engine, that boosts performance for database operations.

Among capabilities supported by VAST Query Engine in release 5.4.0 are vector search, row/column-level security, and filter pushdown.

VAST Database clients can access the query engine using the VAST ADBC driver that connects to a dedicated virtual IP pool using a preconfigured S3 user account. The virtual IP pool must be assigned the new Query Engine role.

For more information about VAST Query Engine and VAST ADBC driver, see VAST Cluster Administrator's Guide.

VAST Database Row/Column-Level Security

You can control access to information stored in a VAST database table by defining the permissions at the row or column level.

The row or column permissions are specified in an identity policy or a bucket policy. The policies must use a new format for the VAST DB row and column permission statements, where resource is a VAST database table or view.

To build an identity policy with this type of statements, open the VAST Web UI policy editor (User Management -> Identity Policies -> choose to create or edit a policy) and select Database Row/Column Security in the Define Statements pane, then specify the resources to be included or excluded, and set row filters and column masks as needed.

The following requirements and limitations apply:

  • Row filtering and column masking are supported for Trino query engines only.

  • The Trino user's identity policy must have the  EndUserImpersonation and  GetRowColumnSecurity actions allowed.

For more information about this feature, see VAST Cluster Administrator's Guide.

Sorted Tables in VAST Database

VAST Cluster 5.4 adds support for sorted database tables. Sorted tables drastically improve performance for selective queries. After sorting has been enabled for a table, a background task keeps it sorted as rows are being added and deleted. Queries against the table can be run during the sorting.

Sorting can be enabled via VMS and from the Trino query engine or VAST Python SDK. To enable sorting on a table and set the sorted columns via VMS:

  • In VAST Web UI, for a new table, use the new Enable Table Sorting option in the Add Table dialog (VAST DB -> VAST Database -> browse to the schema -> choose to create a new table). Alternatively, if the table has already been created, navigate to it and select Enable Table Sorting in its action menu.

  • In VAST CLI, list the sorted columns on the --sorted-column-names option of the table create or table modify command.

To view sorted columns in a table:

  • In VAST Web UI, navigate to the table from the VAST Database page and open its properties.

  • In VAST CLI, use the --list-sorted-columns option on the column list command.

For each sorted table, a sorting status is provided, which is determined based on the amount of rows already sorted. A table is guaranteed to reach the sorting score of Sorted. It may reach the status of Super sorted depending on how pre-ordered the existing table data is.

The following limitations apply:

  • Once enabled for a table, the sorting cannot be disabled.

  • Sorting can be performed for tables that contain 512k or more rows. Although you can enable sorting on a table regardless of its size, smaller tables do not get sorted.

  • Once sorted, tables cannot be unsorted or have their sorted columns changed.

  • Only one sorting order can be defined on a table. Up to four sorted columns are supported.

  • Sorted column values cannot be updated to different values.

  • Sorted tables cannot be replicated. Tables that are replicated cannot be sorted.

  • Sorting cannot be enabled on tables that have semi-sorted projections. Semi-sorted projections cannot be added to sorted tables.

  • Nested data types are not supported for sorted columns.

  • Tables that expose the internal row ID with the vastdb_rowid column cannot be sorted.

  • When calculating the sorting status, a constant value within the Sorted value range is returned for tables that contain less than 5 million rows.

Warning

Some background tasks related to processing of sorted tables might transiently consume space beyond quota limits, resulting in quota exceeded alerts for the users.

Support of Vector Operations

VAST Cluster 5.4  adds support for the vector data type (arrays of floats), enabling users to run similarity queries against a VAST database. Vector operations are supported with both VAST Query Engine and VAST Python SDK. For more information and examples, see VAST Cluster Administrator's Guide.

The following limitation applies:

  • VAST Cluster 5.4.0 does not include performance optimization for vector operations.

Running Trino Clusters on VAST

In addition to running managed Spark applications, you can configure and run a Trino cluster on your VAST cluster.

To set up a Trino cluster, you select the CNodes, set the limit for CNode resource utilization, configure networking and upload a YAML configuration file that defines all the necessary Trino settings. A template YAML file is provided for your convenience. If you want to secure the connection with TLS, you can also upload the TLS certificate and the keys.

You can run Trino and Spark applications concurrently on the same VAST cluster. In this case, a separate set of CNodes is required for each of the applications.

VAST Web UI has been updated to let you select the Trino application type in the Application field of managed application settings (Data Engine -> Applications -> choose to create or edit an application).

The following rules and limitations apply:

  • Trino 475 is supported.

  • Not less than three CNodes are required per Trino cluster (one for the coordinator, two or more for the workers).

  • In case of CNode HA events, the Trino cluster remains accessible and running queries as long as one coordinator CNode and one of the worker CNodes are up.

  • A VAST cluster upgrade (NDU) performed while running a Trino cluster may cause Trino query failures. The Trino cluster will be fully operational after the NDU is complete.

Provisioning for Deployment of User Functions and Pipelines

VAST DataEngine offers VAST cluster tenant users an ability to create and run functions and pipelines triggered by certain types of events or schedules. A user can write application code in Python and host it on Kubernetes, letting the VAST cluster manage all infrastructure aspects of the deployment.

To make the process as simple as possible, VAST provides a new dedicated web-based UI, CLI and REST API for VAST DataEngine users to write and manage their application code. The new interfaces are only available for authorized users of a tenant for which VAST DataEngine provisioning has been enabled, and can be used to create, modify, delete and view functions, pipelines and triggers, and also to deploy and run functions and pipelines.

A set of built-in functions is available which can be used as building blocks to model use cases.

Deployment of VAST DataEngine involves setting up a dedicated VAST Event Broker view or third-party event broker (to stream events to), and also connecting the VAST cluster to a container registry (to store images of functions to be deployed) and a Kubernetes cluster (to consume the events and run the functions on them).

For more information about VAST DataEngine, see  VAST DataEngine User Guide and VAST Cluster Administrator's Guide.

In addition to the new dedicated interfaces, the following user controls have been added for this feature in VMS:

  • To enable DataEngine for a tenant:

    • In VAST Web UI, the new Enable DataEngine option in the context menu for a tenant listed in the Element Store -> Tenants page. This option starts a wizard that lets you enable the functionality for the tenant, assign a VAST Event Broker view, connect to a Kubernetes cluster and a container registry.

  • To configure a dedicated virtual IP pool for DataEngine:

    • In VAST Web UI, go to virtual IP pool settings (Network Access -> Virtual IP Pools -> choose to create a pool -> General pane) and select Query Engine in the Role field.

  • To manage Kubernetes clusters and container registries, use the  Data Engine -> Kubernetes clusters and  Data Engine -> Container Registry pages in VAST Web UI.

  • To set up application user group and permissions:

    • In VAST Web UI:

      • When adding an administrative role (Administrators -> Administrative Roles -> choose to create or edit a role), you can select the Tenant admin / Application user option to indicate that the role will be used to grant permissions for application users.

      • The Users group field in the Who Can Access This Tenant (Data Engine)pane of User Access Management tab in tenant settings (Element Store -> Tenants -> choose to edit a tenant) lets you specify the application user group.

      • Identity policy settings include a new field named Resource type where you can select Data Engine and proceed to entering statements that are applicable for DataEngine.

    • In VAST CLI, use the following options on the he tenant create and tenant modify commands:

      • --application-users-group-name

      • --enable-data-engine-role and --disable-data-engine-role

      • --enable-data-engine-s3-policy and --disable-data-engine-s3-policy

The following limitations apply:

  • If VAST DataEngine is enabled on the cluster, replication of the tenant's root directory is not allowed.

  • Up to 32 engines are supported per VAST cluster.

  • ORION-288279: VAST DataEngine does not support timestamps with a time zone.

Known issues are as follows:

  • ORION-293900:  When streaming S3 event notifications or VAST DataEngine function-triggering events to a VAST Event Broker view on a cluster with multiple VAST Event Broker views belonging to different tenants, some of the event notifications may encounter a flow that prevents them from being sent to their destination. If this occurs, an Internal Kafka target supported only a single tenant GUID, got 2 alert will be raised. With VAST DataEngine enabled, this issue may result in some functions not being triggered as expected.

  • ORION-292066: In VAST DataEngine UI, when trying to connect to a Kubernetes cluster from a VAST tenant that has upper-case letters in its name, the request fails with an Invalid value: <...>: a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character error.

  • ORION-288909: When trying to list logs or traces in VAST DataEngine CLI, the --tenant option on the CLI command does not work as expected.

Replication and Global Access on the Same Path

VAST Cluster 5.4.0 adds support for a configuration where the protected path which is the source for asynchronous replication, is also configured as a Global Access source path, while the replication destination path is used as the Global Access destination path. (Prior to this release, use of the same destination cluster was not supported.)

This configuration requires that asynchronous replication is enabled first, and then the Global Access configuration is enabled.

The following user controls have been added for this purpose:

  • In VAST Web UI:

    • The Activate global access and Activate on source as well flags in the destination settings of a remote protected path (Data Protection -> Protected Paths -> choose to create a path -> open destination settings)

    • The Replication and Global Access data service type in VAST Data Space (VAST Data Space -> choose to add a new data service)

  • In VAST CLI:

    • The --source-member-capabilities option on the protectedpath create, protectedpath add-stream, protectedppath modify-member commands

Security Token Service (STS), IAM Roles and OIDC Providers

VAST Cluster lets you provide users with temporary S3 access keys to enable short-term access to S3 buckets based on a security token sent to the new VAST Security Token Service (STS).

The user sends an assume role request to the VAST STS. The request contains the username, the IAM role to be assumed, and a JSON Web token (JWT) (retrieved from the authentication provider). VAST STS validates the JWT and responds with a temporary S3 access key that provide access permissions according to the assumed role.

You need to define the IAM roles to be assumed on the VAST cluster. An IAM role definition includes associated identity policies (optionally, to specify permissions that this role will grant) and a trust policy. A trust policy determines if a specific JWT is allowed or rejected.

The following user controls have been added for IAM roles:

  • To view and manage IAM roles on the VAST cluster:

    • In VAST GUI, the new User Management -> IAM Roles page

    • In VAST CLI, the iamrole * commands.

  • To specify that the owner of an S3 bucket is a IAM role:

    • In VAST Web UI, the User and IAM Role toggles in S3 general settings of a view (Element Store -> Views -> choose to create or edit a view -> S3 tab -> General pane)

    • In VAST CLI, the --bucket-owner-type option on the view create and view modify commands.

  • To view and manage the association between a IAM role and a user QoS policy:

    • In VAST Web UI, the IAM Role option in the Users or IAM Roles dropdown when editing a user QoS policy (Element Store --> QoS policies -> choose to create or edit a QoS policy -> select the User policy type and go to the User tab)

    • In VAST CLI, the --attached-iam-roles option on the qospolicy create,  qospolicy modify, qospolicy show commands.

  • To view IAM roles for a user quota:

    • In VAST Web UI, the IAM Role Accounting tab when editing a user quota (Element Store -> Quotas -> open a user quota)

    • In VAST CLI, the --iam-role-rules option on the quota show command.

Users are authenticated by a third-party OpenID Connect (OIDC) provider, which issues a JWT with which the user requests to assume a role. To create and manage OIDC providers on the the VAST cluster:

  • In VAST Web UI, go to User Management -> VAST Providers page, open the Add New Provider dropdown and select OIDC from the list.

  • In VAST CLI, use the oidc * commands.

To manage the association between an OIDC provider an a VAST tenant:

  • In VAST Web UI, use the Providers and User Access -> Set Providers -> OIDC tab in tenant settings (Element Store -> Tenants -> choose to create or edit a tenant).

  • In VAST CLI, to create the association, specify the --oidc-provider-id option on the tenant create or tenant modify command. To remove the association, use the --detach-oidc-provider option on the tenant modify command.

STS operations are subject to VAST audit logging. To enable logging of STS operations:

  • In VAST Web UI, select STS in the protocol selection field in global audit settings (Settings -> Auditing -> Global Baseline Audit Settings -> Select protocols to assign operations).

  • In VAST CLI, specify the STS value on the --audit-protocols option of the cluster modify command.

The following restrictions and limitations apply:

  • STS is supported with HTTPS only.

  • Use of STS requires that the S3 protocol is enabled for the cluster.

  • One OIDC provider per VAST cluster tenant.

  • When replicating IAM roles:

    • ORION-278747: IAM role replication may take several minutes to complete in case the cluster is under high load or there is a very large amount of roles to replicate.

    • STS access keys are replicated only when the protection path is in SYNC state.

    • ORION-278217: When processing the assume role operation, the cluster may be raising a Failed to replicate STS temp keys alert until the synchronous replication stream/protection path reaches the SYNC state.

  • ORION-285727: In some rare cases when IAM roles are subject to replication, if you delete an IAM role on a replication source, the deleted role gets recreated as a result of the replication. The recreation might take place, for example, in case a HA event occurs during role deletion, or if you modify the role on the replication destination (at the same time as the role is being deleted on the replication source). If you encounter this issue, delete the recreated role again both on the replication source and destination.

  • ORION-287563: Only five OIDC keys can be returned for a manual request to get or refresh OIDC keys.

Monitoring of Data Pending Deletion and Total Snapshots Capacity

VAST Cluster offers an ability to monitor two new metrics, which in sum represent the cluster's auxiliary capacity:

  • How much data is pending deletion on the cluster, i.e. expected to be deleted by VAST asynchronous processes without further user interaction (such as data in the Trash folder).

  • How much capacity is used to store snapshots, i.e. how much space will be freed if all of the snapshots are deleted.

The new metrics are shown on the cluster's dashboard as Pending Deletion and Snapshots usable and logical capacities, replacing the deprecated Auxiliary capacity metric in the Capacity widget.

The Cluster Auxiliary Capacity analytics report has been enhanced to include both new metrics.

YAML-Based Drive Compatibility Validation

When adding a new drive to the cluster as part of the cluster expansion or field replacement procedure, the cluster checks the drive against the list of supported drives and raises an alarm if the new drive is not found on the list. Non-supported drives are rejected.

Drive compatibility information is maintained using a YAML file (provided and signed by VAST Support) that contains detailed information for the supported drives. This eliminates the need to run a cluster upgrade each time new drives are qualified to be used in VAST clusters.

YAML-based drive compatibility validation is enabled by default. If you want to have it disabled so that drives are verified against a hard-coded list initially supplied with the product, contact VAST Support.

The following user controls have been added for this feature:

  • In VAST Web UI, the new new Support -> Drive Compatibility page in VAST Web UI lists drives that are compatible with the current VAST Cluster version. For each drive, the page indicates the drive model name and number, supported firmware versions, capacity and role (boot drive, SSD, SCM).

  • In VAST CLI, the supporteddrives list and supporteddrives get commands

The following known issue was encountered for this feature:

  • ORION-275610: The Drive Compatibility page in VAST Web UI (Support -> Drive Compatibility) does not display all of the details that are available when running a supporteddrives list or supporteddrives get command of VAST CLI.

Related articles
  • New Features in 5.3.0
    VAST Cluster > Version 5.3 > Version 5.3 Release Notes > VAST Cluster 5.3.0 Release Notes
  • Enhancements in 5.3.0
    VAST Cluster > Version 5.3 > Version 5.3 Release Notes > VAST Cluster 5.3.0 Release Notes
  • New Features in 5.0.0
    VAST Cluster > Version 5.0 > VAST Cluster 5.0 Release Notes > VAST Cluster 5.0.0 Release Notes