When we went deep on Dell PowerStore Gen 3 earlier this year, the story was hardware, and there was plenty of it. Dell rebuilt the platform from the chassis up: 40 E3.S NVMe bays in 3U with no slots burned on cache, a 200GbE RDMA midplane between controllers that is decoupled from CPU generations, Software-Defined Persistent Memory in place of NVRAM drives, PCIe Gen 5 end-to-end, and OCP 3.0 I/O modules replacing the proprietary SLIC carriers. Every one of those choices was made to support a ten-year service life with multiple in-place controller upgrades, which is what made the platform’s Lifecycle Extension story concrete.

The fully populated Gen 3 hardware. The other half of the story is PowerStoreOS 5.0.
At the time of that hardware launch, PowerStoreOS 5.0 was still under wraps. It’s generally available now, running on new shipments of Gen 3 systems and available for download for the existing install base, so we took a look at what’s new and what’s been further enhanced. The short version: the interesting work in this release is operational. OS 5.0 is less about a single headline feature and more about making a mixed fleet of PowerStore generations behave like one system, squeezing more efficiency out of the new hardware, and putting sharper eyes on performance and security.
One OS, Every Generation
The most consequential aspect of PowerStoreOS 5.0 is where it runs. This is not a Gen 3 exclusive; the same 5.0 release that ships on a new PowerStore 1500 can be downloaded to Gen 1 and Gen 2 appliances. Some capabilities are naturally gated by hardware (encrypted data-in-flight FC cards being a prime example), but the operating environment itself spans the entire install base.

One cluster, two generations, both media types: a Gen 2 1200T and 500T alongside a Gen 3 9500 running QLC.
That matters because of clustering; Gen 1, Gen 2, and Gen 3 appliances can coexist in a single PowerStore cluster with non-disruptive workload mobility between them. The demo environment Dell walked us through makes the point clearly: a 1200T that began life as a Gen 1 1000T and was upgraded in place, clustered alongside a Gen 3 appliance, all managed from a single PowerStore Manager instance. PowerStore Manager now displays the generation of each appliance in the cluster view, along with its storage class, so a mixed estate is easy to see at a glance. One planning note: clustering is one-way for the new hardware. Gen 3 appliances can join a Gen 2 cluster, but not the other way around. Once a Gen 3 appliance is added, additional Gen 2 appliances can’t be added, a rule the initial configuration wizard states up front.
For customers on older PowerStore hardware, this is the migration path. Add the Gen 3 appliance to the existing cluster, migrate volumes natively in PowerStore Manager with an automatic cutover once the data is migrated, and retire or repurpose the old appliance once it is empty. Block migration works this way today; file migration between appliances in a cluster is slated for the next release. In the interim, Dell points file customers to replication, to native file migration from Unity or VNX, or to host-based moves, such as Storage vMotion, for virtualized estates. We monitored a live Unity NFS import during our session, and the flow will be familiar to anyone who has retired an EMC-era midrange array: discover the source, pair the file systems, copy in the background, then take a short cutover window while the PowerStore assumes the personality of the old system. With tens of thousands of Unity systems still in the field by Dell’s own estimate, that import path is going to stay busy.

Gen 2 initial configuration still asks the question: Unified or Block Optimized.

On Gen 3, the choice is gone: unified by default, with resources allocated dynamically.
On Gen 1 and Gen 2, deployment starts with a choice: unified or block-optimized. Choosing unified statically carves out a slice of CPU and memory for the NAS container, whether the file is ever used or not, meaning block workloads pay for file headroom that may sit idle. On Gen 3, that choice is gone. Every appliance deploys unified, and Dynamic Core Allocation shares resources between block and file services on demand. File gets the resources it needs rather than the resources a wizard guessed it might need, and block reclaims everything else. Metro replication also spans generations; flipping the preferred role on an active-active Metro volume pair between a Gen 3 and a Gen 2 appliance takes a single click, and the switch is completed in under a second.
TLC or QLC: Right Storage for the Workload
Every Gen 3 model, 1500, 5500, and 9500, accepts either TLC or QLC E3.S drives with no separate model tiers and, per Dell, no performance trade-off between media types. The T and Q suffixes that were used to split the lineup are gone with Gen 3; the model defines the platform, and the drive type is whatever you need for your use case.
The software making that possible is the autonomous data path work in OS 5.0, which applies per-I/O intelligence to placement and de-staging so high-capacity QLC has room to deliver. Under the covers, writes land in DRAM, are mirrored between nodes across the RDMA interconnect rather than over the CPU-mediated path older generations used, and are acknowledged back to the host without touching the drives. On de-stage, the system aggregates reduced data into full-stripe writes to the back end, which keeps write amplification down, a property that matters most for QLC endurance. Dell credits the reworked data path with up to 2x faster reads, consistent with the underlying hardware.
Capacities run 3.84TB, 7.68TB, and 15.36TB in TLC plus 30.72TB in QLC; fill all 40 bays with QLC, and Dell puts the headline number at 5.8PB of effective capacity in 3U, an effective figure that assumes the full 6:1 reduction. Dell has also lowered the barrier to QLC entry: a Gen 3 1500 starts at seven 30.72TB QLC drives, where the prior generation’s QLC configurations required a minimum of eleven. We have watched Dell’s QLC posture evolve since the PowerStore 5200Q brought QLC to mainstream workloads; with Gen 3, the QLC-versus-TLC decision finally reduces to dollars per gigabyte and density rather than a performance tier.

On Gen 2, front bays go to NVRAM cache drives.

On Gen 3, all 40 bays hold data; cache persistence moved into Software-Defined Persistent Memory.
Efficiency and the 6:1 Guarantee
Gen 3 changed the on-disk geometry: the page size moved from 4K on earlier generations to 8K. That halves the metadata the system has to track per terabyte, which returns capacity and processing headroom to user workloads. However, taken alone, it would be a step backward for deduplication, since two 4K blocks that previously deduplicated independently might now be split across different 8K pages. OS 5.0’s answer is unaligned deduplication. Rather than only matching pages on 8K boundaries, the system can find duplicate 8K blocks that straddle page boundaries and reduce them anyway. It requires more processing, which is exactly the kind of work the Gen 3 hardware has cycles and newer offload silicon for. Enhanced compression offloads round out the data reduction pipeline. The geometry change is transparent to hosts and applications; nothing on the initiator side needs to be reconfigured.
That pipeline is what stands behind the headline DR number. Dell raised its data reduction guarantee from 5:1 to 6:1 with this platform, and the qualifier travels with the number: the 6:1 guarantee applies to Gen 3 arrays initially installed with OS 5.0, on reducible data. Dell’s engineers were direct with us about the mechanics: if a qualifying customer does not see 6:1 on reducible data, Dell makes it right with additional drives. The company credits the combination of newer QAT offload generations, faster processors, the RDMA cards relieving the CPUs of inter-node transport, revised data striping, and years of fleet telemetry from Dell AIOps (formerly CloudIQ) that showed where the reduction algorithms were leaving savings on the table.
Dell supplied two Capacity Dashboard captures from a lightly loaded cluster (1.4% of physical capacity in use) to show how those numbers surface in PowerStore Manager. The Data Savings panel reports an overall DRR against everything written and a separate reducible DRR that excludes data the array has classified as unreducible, with that unreducible portion called out in GB. In the first capture, 2.5TB of logical data lands in 359GB of physical space, a 7.2:1 overall DRR and 11.7:1 on the reducible portion.

Dell PowerStore Capacity Dashboard: 7.2:1 overall DRR and 11.7:1 reducible DRR on 2.5TB of logical data (Dell-supplied capture).
The second capture, with more data written to the same volumes, shows 2.7TB logical in 376.4GB physical for 7.4:1 overall and 12.3:1 reducible. The dashboard also rolls snapshot and thin provisioning savings into an overall efficiency figure (29.5:1 and 28.2:1 here), which is the number to leave out of any 6:1 conversation, since the guarantee is scoped to data reduction on reducible data. These are Dell’s captures of a Dell data set, so treat them as a demonstration of the reporting. What a given production workload reduces to is a separate question.

The Data Savings panel at 7.4:1 overall DRR, with snapshot and thin savings rolled into a 28.2:1 overall efficiency figure (Dell-supplied capture).
NAS, Nutanix, and the External Storage Story

Prism Central attaches PowerStore as external storage for AHV clusters.
Following the partnership that brought PowerStore to Nutanix NCI 7.6 as external all-flash storage for AHV, OS 5.0 lets PowerStore Manager get more integrated. Nutanix builds its storage out of many volumes, in the same way VMware decomposes VMs into files; a couple hundred VMs on AHV can translate into 4,000 volumes on the array. Prior to 5.0, those volumes appeared in the general volumes view, burying everything else. Now, when a Nutanix cluster attaches, PowerStore Manager adds an Externally Managed Volumes tab (and a matching Externally Managed Hosts tab) that quarantines the Nutanix objects into their own view, each tagged with a Nutanix application type. Storage admins get their volume list back, and the tab simply does not exist on systems without Nutanix attached.

The Externally Managed Volumes tab keeps thousands of Nutanix-created volumes out of the main view.
Attaching PowerStore runs from Prism Central: select Dell PowerStore as the external storage vendor, point it to PowerStore Manager, and the integration handles volume creation and mapping on the Nutanix side. For shops hedging their hypervisor strategy, the underlying array stays the same, while the platform on top remains negotiable.
Mobility work in 5.0 also extends to OpenShift. PowerStoreOS 5.0 integrates XCOPY offload with Red Hat’s Migration Toolkit for Virtualization, so VM migrations offload the copy work to the array instead of routing data through the host over iSCSI or Fibre Channel, including multi-disk VMs. For customers moving VMs toward KubeVirt, that pairs naturally with the Automation Platform story later in this piece: migration traffic the host never has to touch.
Sharper Eyes on Performance

Utilization decomposed: CPU, caching media, front-end ports, and back-end at a glance.
OS 5.0 brings a set of new performance dashboard widgets that make the array’s headroom easier to visualize. Performance Utilization decomposes appliance load into its constituent parts, so a utilization number is no longer a mystery: hover over a point on the chart to see how much is CPU, caching media, front-end ports, and back-end drives at that moment, along with latency. The widget also carries a Sustained IOPS view, and once the system has collected about two weeks of history, a Forecast toggle projects utilization and latency forward with confidence ranges, three months out in our screenshots.

The forecast view projects utilization and latency three months out, with confidence ranges.
Anomaly detection itself arrived at the appliance level in PowerStoreOS 4.2. What 5.0 adds is promotion to the dashboard, with a dedicated widget covering six metrics (bandwidth, total, read, and write IOPS, latency, and average I/O size), side-by-side comparison across appliances, and exportable results. The mechanics are unchanged: after building a baseline of roughly 72 hours of history, the array learns each workload’s behaviors and paints the expected band behind the live metric, flagging excursions rather than waiting for a static threshold to trip. The screenshots tell the story: bandwidth wobbling inside a grey historical-seasonality envelope, with the tooltip reporting the observed value, the expected range, and an explicit anomaly verdict.

Anomaly detection paints expected seasonality behind the live metric and flags excursions.
Headroom also grows in the limits table. 5.0 raises the clone limit per volume family from 256 to 1,000 (Gen 2 models above the 500 and all Gen 3, automatically on upgrade), doubles volume-to-NVMe-host mappings to 32,000 on the high-end 9XXX models, lifts NAS server interfaces to 1,000 and file systems to 14,000 on larger Gen 2 and Gen 3 systems, and adds file-limit notifications at 80, 90, and 99 percent so the ceiling never arrives as a surprise.
The same I/O-level telemetry underneath these views is the groundwork Dell has laid for inline ransomware detection on the array itself, which the company positions as coming soon.
Cyber Resilience: MPA, Dell Cyber Detect, and Keys
Security work in 5.0 splits into three tracks: hardening the humans, scanning the data, and managing the keys.

MPA in PowerStoreOS 5.0: protected actions are now chosen, not imposed.
Multiparty Authorization was introduced in an earlier release as an all-or-nothing switch: enable it, and every destructive action on the cluster requires a second admin’s approval. OS 5.0 makes it granular. Admins now choose from a catalog of 61 protected actions across compute, storage, protection, system, hardware, and settings categories, with 41 protected by default, and tune the list to their own tolerance. One shop might require approval for every snapshot deletion but let protection policy edits through; another might want a second set of eyes on user deletions but not on SMB share changes.
Approval timeouts are now configurable from three to seven days rather than fixed at seven; email notifications and reminders keep requests from dying in a queue, and the whole configuration applies cluster-wide, following automatically when a new appliance joins. Even the approval flow itself is MPA-protected: modifying the protected action list generates a request that a second admin must approve, and the audit trail records who requested it and who approved it. Everything is exposed through REST, so a service provider with dozens of arrays can script a golden MPA configuration across the fleet.

Per-category granularity across compute, storage, protection, system, and settings.

Dell Cyber Detect is Index Engines’ CyberSense technology, integrated for PowerStore.
Dell Cyber Detect is the company’s integration of Index Engines’ CyberSense analytics, an integrated offering that runs alongside the array rather than code inside OS 5.0; this is the same full-content analysis engine the industry knows from PowerProtect. Pointed at PowerStore, it scans snapshots for statistical fingerprints of corruption and encryption events, with policies configured via a wizard that connects to the array, selects production hosts, and schedules scans over iSCSI or FC. What administrators get out of it is a catalog of snapshots verified clean, so recovery after an attack starts from a known-good copy. That pairs with PowerStore’s secure snapshots, which can’t be deleted before their retention period expires, even by an administrator, so the clean copies Cyber Detect identifies are also the copies an attacker can’t remove. Between Cyber Detect on the data, AIOps ransomware monitoring on the telemetry, and MPA on the control plane, the ransomware story now covers content, behavior, and blast radius.

A Cyber Detect scan policy is reviewed before creation: array, hosts, connection, and schedule.
The third track was a direct customer ask, particularly from government-adjacent shops: encryption key rotation for data at rest (D@RE) is now user-controllable. Where key management previously lived entirely under the covers, 5.0 lets an admin generate a new set of keys on demand, on their own compliance clock, and download the keystore. Dell described this as the first phase, with scheduled rotation on the roadmap. Gen 3 hardware adds two more layers that ride along: firmware signed with post-quantum cryptography, positioning the platform against harvest-now-decrypt-later strategies, and FIPS 140-3-compliant SDPM, so cached data awaiting de-stage is protected to the same standard as data on the drives.
AI Recommendations: From Insight to Action
As of July, Dell AIOps (formerly CloudIQ) and the Dell Automation Platform work together to connect AI-driven recommendations with automated optimization, through an integration that’s currently in limited availability.
The combination gives operators a more direct path from insight to action, with human oversight and digital twin technology there to build trust in what the system proposes. Users move from a recommendation to an automated action inside a single interface, which Dell has redesigned as a generative UI: chat-first and minimal by default, with users generating the tables, charts, and views they need and pinning them into persistent, personalized workspaces.

The generative UI in its launch dark mode: a pinned workspace with fleet health, IOPS, and inventory widgets built from chat.
At launch, there are three actionable use cases, two of them PowerStore-specific. Continuous capacity optimization surfaces reclaimable storage, volumes with no host mappings or no recent I/O, and walks the admin from recommendation through actual reclamation without ever opening PowerStore Manager. System updates for PowerStore let an admin set a code-level tolerance, target installation dates, batch sizes, and repeated pre-upgrade health checks, then execute the update plan from the same conversation, with a failed update generating a support ticket. The third use case scales Dell Private Cloud clusters by identifying over-provisioned VMware-based clusters and consolidating nodes that workloads no longer need, while retaining nodes the cluster still requires.

Continuous capacity optimization at work: 2.0TB freed across three volumes, with utilization before and after.
Two design decisions stand out. First, every action is human-in-the-loop, with the system presenting its plan and reasoning, answering “How did you come up with this recommendation?” in plain language, and waiting for explicit approval. A digital twin of the customer environment, arriving shortly after the initial launch, will verify downstream impacts before changes are executed. ServiceNow change-control integration is in development, so approvals can be gated on a ticket. Second, licensing doesn’t change: AI Recommendations comes with AIOps, which comes with a Dell ProSupport or higher contract, so for most PowerStore shops, the capability is available.

Human-in-the-loop, end-to-end: an update plan with one failure and the support ticket raised from the same conversation.
Private Cloud, Automation Platform, and MCP
Below the AI Recommendations layer lies the machinery that deploys and runs the private cloud. With the Dell Automation Platform orchestrator, an admin picks a blueprint, uploads a JSON configuration (or fills parameters manually), and watches an execution graph walk through a full environment deployment. This includes PowerStore hardware validation, compute and networking preparation, and hypervisor installation, with the storage steps folded directly into the workflow, from connecting PowerStore volumes to VMkernel adapters over iSCSI to installing CSI drivers when Kubernetes is in play. The hypervisor menu spans VMware, Red Hat, Nutanix, and Microsoft Azure Local, and Dell Private Cloud extensions install into each platform’s own console, vSphere Client, OpenShift Web Console, Prism, or the Azure portal. So day-two lifecycle management of VMs and containers happens in the tools teams already use. Dell can close the loop by deploying a Windows VM to KubeVirt on OpenShift through that same extension, consolidating container and VM operations in one place.

The orchestrator’s execution graph walks a PowerStore-backed VMware deployment step by step, with per-step logs.

The Dell Private Cloud plugin lands in vSphere Client, with the PowerStore iSCSI datastore ready for the cluster.

The blueprint catalog spans VMs, Kubernetes, public cloud, OS, and databases; Automation Studio adds AI-assisted custom orchestration.
The blueprint catalog is the interesting part for workload owners. Alongside the infrastructure blueprints, Dell Automation Studio lets customers build custom orchestration. Dell’s showcase is a database-as-a-service pattern: a PostgreSQL blueprint deployed on a PowerStore-backed datastore atop vCenter, with the application installed through Ansible. Logging is unified across the VMware and Red Hat steps of the job, and live cloud-init and VM initialization logs stream into one reporting view while vSphere does the standup. The vSphere side runs through a platform plugin built on the VMware SDK, and when the Ansible actions complete, the database is in place and serving. The pitch to PowerStore customers is that the array stops being a destination you provision to and becomes a resource the platform composes automatically.
Where this all heads is agentic. Dell’s own launch language is explicit: the Automation Platform “pairs AI agents with a conversational interface to transform how companies deploy, monitor and manage infrastructure,” and the platform’s agentic AI capabilities are planned for later this year. Dell has acknowledged it’s working on MCP servers in response to customer demand to bring their own agents, with an MCP server for Dell storage coming first. The Dell Technologies Developer site already describes what’s coming: more than 100 MCP tools across PowerStore, PowerScale, PowerProtect, PowerFlex, PowerMax, and ObjectScale, with general availability targeted for the end of the year. Tools and parameters are derived from each platform’s versioned OpenAPI spec, so a model can’t invent calls that don’t exist. It can run as a local process, an HTTP server, or a Kubernetes sidecar, every mutation gets a structured audit log, and bulk destructive operations require dual confirmation. MCP has quickly become the standard interface for providing AI agents with structured, permissioned access to enterprise systems. An MCP server for the Automation Platform would enable a customer’s own agents to drive the same blueprints, recommendations, and telemetry that the platform’s native agents consume. We expect the MCP story for the platform to firm up alongside the agentic rollout, and we’ll cover it when it does.
What’s Next: The Cadence Continues
PowerStoreOS 5.0 is out now, but Dell’s release cadence iterates quickly to meet customer needs, and the team is already deep into 5.1, due out this fall. Dell is holding the full 5.1 feature rundown for closer to release, but one thread is already locked in: encryption in flight.

The EDIF-capable quad-port Fibre Channel OCP card from our Gen 3 lab unit; the hardware ships today, and the encryption arrives in software.
Every PowerStore Gen 3 can be configured with EDIF-capable Fibre Channel cards in its OCP slots today; the encryption itself arrives through a non-disruptive software update, which is why it headlines the 5.1 conversation. EDIF (Encrypted Data-in-Flight) encrypts Fibre Channel traffic on the wire between host and array, or between two replicating arrays, closing a gap firewalls never touched: internal SAN traffic moving in cleartext. Because the array decrypts on receipt, deduplication and compression still see reducible data, so the wire gets protected without giving back the efficiency gains this release worked so hard to further improve. Encrypt at the host or application layer instead, and every block arriving at the array is unique noise; EDIF protects the transport without paying that tax.
The other half of the story lives on the server. We have covered Emulex Secure HBAs in depth, hardware-offloaded, session-based encryption in the adapter itself, aligned with the emerging FC-SP-3 standard and built for a zero-trust posture on internal traffic, and we have watched the approach mature into autonomous SAN-wide encryption. When 5.1 lights up the array side, end-to-end encrypted Fibre Channel becomes an ordinary configuration on PowerStore.
The article we wrote at the hardware launch ended by looking forward to seeing how Gen 3 and PowerStoreOS 5.0 come together. Now that we’ve spent time with the GA release, the answer is that the software matches the ambition of the chassis it runs on. One OS across three generations of hardware, QLC being mainstream, measurably better efficiency with a guarantee behind it, and an operations layer that is learning to close its own loops, extending what storage admins can accomplish in short order.
There is one more number worth closing on. In July, Dell’s operational telemetry crossed 1 billion cumulative hours of PowerStore runtime across the reporting fleet, representing six years of production experience, which amounts to more than 114,000 machine-years. Fleet learning at that scale is what trained the data reduction tuning, the anomaly models, and the recommendations engine described above, and it is the advantage behind most of what 5.0 does well. The platform’s next billion hours start on much smarter software with an equally capable hardware platform underneath.
Pagina del prodotto PowerStore
Questo rapporto è sponsorizzato da Dell Technologies. Tutti i pareri e le opinioni espressi in questo rapporto si basano sulla nostra visione imparziale dei prodotti in esame.




Amazon