DBox decommission, block QoS, mTLS, replication, and the rest of the operational changes admins need to know before they upgrade

Where This Fits

VAST AI OS 5.5 went generally available today, August 6, 2026. Most of the launch attention, understandably, is going to the AI-facing side of the release: the Hyperscale Vector Index, native SQL analytics, and DataEngine’s new compute layer. I covered all of that in a companion post. i covered them here VAST AI OS 5.5 Deep Dive – Lots of Data

This one is about the other half. Underneath the AI headlines, 5.5 also carries a real batch of changes to how a VAST cluster gets operated day to day: a cluster can finally shrink as well as grow, block storage catches up to file and object on QoS and replication, tenant identification gets a cryptographic upgrade, and the multi-tenancy ceiling jumps by nearly an order of magnitude. None of it is as flashy as trillion-vector search, but if you’re the one who actually runs the cluster, this is the part of 5.5 that changes your week.

The full 5.5 feature summary, grouped by AI OS pillar. This post covers DataStore, DataSpace, and Cloud; the companion post covers DataBase and DataEngine.

VAST DataStore: Operational Flexibility and Protocol Depth

DataStore is where 5.5’s most operationally significant change lives: the ability to shrink a cluster, not just grow one.

DBox Decommission

Until now, a VAST cluster’s disaggregated architecture made it easy to add capacity but not to remove it. 5.5 introduces DBox Decommission: the ability to fully remove a DBox, EBox, or VAST-on-Cloud instance from a running cluster with no outage and no downtime. When a DBox is removed, the remaining cluster automatically rebalances so every SSD and SCM device keeps its full resilience guarantees.

DBox Decommission: removing storage nodes without downtime or data movement risk.

• Decommission older-generation hardware without a forklift migration
• Shrink an under-utilized cluster, then redeploy the freed DBoxes elsewhere
• Swap in newer hardware or return POC/loan equipment cleanly
• Works for both physical clusters and VAST-on-Cloud (VoC) instances

Any cluster that started with two or more DBoxes can be reduced back down to a minimum of two, and clusters that grew from one DBox to two can shed the addition again. The system still enforces hard limits: it won’t let a decommission proceed if it would leave insufficient data or metadata capacity, break the CNode-to-DBox shard ratio, or violate RIO stripe-size constraints. So this is capacity flexibility with the same resilience guarantees VAST customers already rely on.

One data-handling detail worth flagging for anyone planning a decommission: there’s currently no automatic erase step when a DBox is removed. If the cluster uses an external key manager (EKM), losing access to the encryption keys already renders the data on those drives unreadable (the data is encrypted, not the drive itself), but the drives themselves aren’t wiped as part of the process. If a hard erase is required, returning leased hardware, for example, that’s a separate step after decommission, using nvme format /dev/nvmeXn1 -s 2 on the drives directly. The official release notes add one more prerequisite worth knowing up front: a DBox removal can only start once metadata rewrite has completed on the cluster (itself a required step when upgrading to 5.5), so this isn’t something you can kick off the moment the upgrade finishes.

NFS mTLS for Tenant Identification

Multi-tenant clusters have historically identified tenants by client IP or VIP pool membership, a model that caps out at 512 VIP pools and is vulnerable to IP spoofing. 5.5 replaces that with certificate-based tenant identification over NFS mTLS: the VAST Management System (VMS) maps mTLS certificates to tenants, and the NFS server uses those certificates to authenticate and route I/O to the correct tenant.

Certificate-based tenant identification replaces IP-based routing for NFS multi-tenancy.

The practical benefit is that a single shared VIP pool can now serve multiple tenants securely, tenant boundaries are enforced cryptographically rather than by network topology, and certificate management becomes centralized in VMS rather than scattered across firewall rules. Two implementation details from the official docs worth knowing: mTLS certificate-based tenant identification for NFSv3 requires the VASTNFS client driver (NFSv4 doesn’t need it), and NFSv3 clients using this feature need to mount with mountproto=tcp.

NFSv4.2 Extended Attributes

5.5 adds support for user-defined extended attributes (xattrs) on files and directories over NFSv4.2. An xattr is a simple key/value pair (user.creator, user.checksum, user.source_url) that travels with the file but sits outside the file’s own content, and 5.5 exposes the full set of NFSv4.2 xattr operations: GETXATTR, SETXATTR, LISTXATTR, and REMOVEXATTR.

NFSv4.2 extended attributes: key/value metadata attached to files, distinct from S3 object tags.

• Richer metadata storage without a separate metadata database
• Better interoperability, since xattrs travel with the file across heterogeneous clients
• A foundation for security labels and policy enforcement (SELinux-style labels, ACL extensions) at the protocol level

Worth being precise about scope here: this is an NFSv4.2-only feature in 5.5. The latest technical materials are explicit that these xattrs are not the same as S3 object tags, even though the two serve a similar purpose on their respective protocols. Xattrs are visible in the catalog, only the user namespace is supported, names are case-sensitive and capped at 1024 characters (128 if a view policy sets length to LCD), and the feature applies to regular files and directories only, not pipes, devices, or symlinks.

S3 Cross-Origin Resource Sharing (CORS) at the Bucket Level

CORS support, already available at the cluster level, now extends to individual buckets. This lets a web application served from one domain make authenticated fetch() calls against S3 resources hosted on a VAST bucket in a different domain, with the browser’s CORS preflight negotiating exactly which methods and headers are permitted. Bucket-level control means different applications sharing a cluster can each define their own cross-origin policy instead of inheriting one cluster-wide rule. The old cluster-wide CORS toggle still works but VAST now calls it out as no longer recommended, since it opens every bucket on every tenant to every origin unless that bucket sets its own rule; any bucket-level configuration takes precedence over the blanket cluster setting when the two disagree.

QoS Enhancements and the Noisy-Neighbor Problem

Quality-of-service policy in VAST has historically applied to file and object protocols at the view and user level. 5.5 rounds that out substantially, adding QoS coverage for block traffic and tightening cluster- and tenant-level controls across the board.

QoS now spans volume, tenant, and cluster-level policy across block, SMB, NFS, and S3, with policy headroom raised to 10k.

• The maximum number of QoS policies per cluster increases to 10,000, up from 4,000
• Per-volume and per-tenant QoS for block traffic, plus cluster-wide read/write limits
• A priority-view QoS policy for SMB, NFS3/4, and S3 that can exceed standard cluster limits for designated workloads
• Three policy modes: static (fixed bandwidth/IOPS), used-capacity (scales with data stored), and provisioned-capacity

The goal is the classic multi-tenant storage problem, a noisy neighbor workload starving everyone else of IOPS, addressed with the same granularity for block that file and object protocols already had.

Block QoS

Concretely, this shows up as a new QoS policy type, “Volume,” configurable through the VMS GUI, CLI, and REST API, with static min/max/burst/credit controls for total, read, and write bandwidth and IOPS. Tenant- and cluster-wide limits get enforced on block traffic automatically too, without needing a policy attached to anything, the same way they already work for the other protocols.

Volume-level QoS policy configuration in the VMS console, with static bandwidth and IOPS controls.

One operational note carried over from the technical documentation: mapping a single host to multiple volumes that share a subsystem is discouraged if those volumes carry different QoS policies, or a mix of policy and no-policy volumes. Because the host’s NVMe driver shares I/O queues across volumes in a subsystem, mismatched policies can make the I/O scheduler behave unpredictably. The guidance is to keep every volume in a shared subsystem on a consistent policy.

Two more limits worth knowing before you lean on this heavily: attaching QoS limits to more than 100 volumes can start producing inaccurate performance capping, and a volume-level policy cannot be prioritized over cluster-wide QoS limits if the two disagree. Clients also need to be configured for round-robin or queue-depth load balancing for block QoS to behave as expected.

Enhanced XCOPY for Block Volumes

XCOPY, VAAI-accelerated copy offload for block, already existed; what 5.5 actually ships is improved performance for XCOPY operations (VM cloning being the main use case) and for SMB server-side copy alongside it. The mechanism itself is the same either way: instead of data traveling up through the ESXi host and back down again, the standard copy path, XCOPY turns a block copy into a lightweight metadata operation. The target simply references the same underlying flash data as the source, committed atomically and finalized in the background, with source and target remaining logically independent from that point on.

Standard copy pulls data through the host; XCOPY offloads the copy to the array as a metadata operation.

• VMware full clones and Storage vMotion complete dramatically faster
• Large-scale VM and data replication offloads from host resources to the array
• SMB server-side copy is supported too (CopyChunk, though not ODX)

VAST DataSpace: Block Joins Async Replication

DataSpace covers VAST’s data-protection and replication layer, and in 5.5 it picks up support for block volumes, previously a gap relative to file and object protocols. The feature was renamed between deck revisions from “Block Protocol with Async Replication” to “Async Replication for Block Volumes,” but the underlying capability is the same.

Async replication now covers protection paths that include block volumes, replicating from a source cluster to a target.

• Protection paths containing block volumes can now be replicated asynchronously
• Source and target subsystem NQNs differ by design, and replication direction can be reversed for failover
• The target path is read-only until a failover promotes it
• Replication works at every level (above, at, or below the subsystem and volume), with group replication to multiple destinations
• CSI-driven replication is supported for both block and file

For customers running block workloads, VM disks, databases, this closes the disaster-recovery gap: a failover can now redirect the source of truth from one cluster to another for block just as it already could for file and object. Two practical gaps to plan around: block host definitions and host-to-volume mappings aren’t replicated, so those need recreating manually at the destination, and on ESXi specifically, a host doesn’t automatically notice that a failed-over volume has become read-only, so someone has to manually unmap it rather than relying on ESXi to detect the change itself.

I wrote an in-depth post + a demo on this here K8s DR with VAST CSI 5.5 & 2.6.6 – Lots of Data

VAST on Cloud: Filling In the Availability Story

VAST on Cloud (VoC) enhancements in 5.5 focus on making the cloud deployment model, VAST Polaris as “AI OS in the cloud,” more competitive on cost, scale, and resiliency.

VAST on Cloud enhancements target persistence, availability, and simpler marketplace deployment.

• Full VAST clusters deployable directly from the AWS and GCP marketplaces
• A lighter single-node test/dev cluster option, also marketplace-deployable
• A clearer availability tiering: single-instance (99.5% SLA), placement-group-protected multi-instance clusters that survive a single failure, and multi-zone clusters that replicate data across zones for higher RTO targets

My View on 5.5

Stepping out of pure technical-overview mode for a moment: laying all of this out in one place is a genuinely great testament to the hard work the team has put into this release. And I’ll say this plainly, because it’s easy to be skeptical of platform buzzwords: the AI OS is not a marketing slogan. It’s a real, working architecture, and 5.5 is the proof.

Taken together, 5.5 is where we’re doubling down where it matters, specifically for running AI workloads in production: block storage catching up to file and object on QoS and replication, database security and SQL depth catching up to what a real analytical workload needs, and a vector index built to scale past the point where most alternatives need a hardware step-function. The compute-inside-the-cluster model for DataEngine is the more architecturally interesting move: it’s us providing more options for customers running pipeline logic next to the data.

Appendix: Official Documentation

Everything above is my own synthesis, written and fact-checked against both internal materials and VAST’s public 5.5 posts. If you want the source of truth rather than my summary of it, these are the official docs I cross-checked this post against, including the full 5.5.0 release notes, which is the single most authoritative list of what actually shipped.

Version 5.5 documentation index: kb.vastdata.com/documentation/docs/version-5-5

VAST Cluster 5.5 Administrator’s Guide: kb.vastdata.com/documentation/docs/vast-cluster-5-5-administrator-s-guide

VAST Cluster 5.5 DataEngine User Guide: kb.vastdata.com/documentation/docs/vast-cluster-5-5-dataengine-user-guide

VAST Cluster 5.5.0 Release Notes (the definitive new-features and limitations list): kb.vastdata.com/documentation/docs/vast-cluster-5-5-release-notes

Related on Lots of Data: VAST AI OS 5.5 Part 1 · VMware XCOPY on VAST AI OS 5.5