How to Discover and Map Pure Storage FlashArray in Your CMDB

TLDR

Pure Storage FlashArray arrays rarely appear in CMDBs because most discovery tools treat storage as out-of-scope. Automated SSH or SNMP-based discovery can populate FlashArray configuration items — including controllers, volumes, hosts, and host-to-volume relationships — directly into your CMDB. This article explains what data is available, how discovery works, and best practices for keeping it accurate.

Introduction

Enterprise storage infrastructure sits at the heart of every critical application workload. Database clusters, virtual machine datastores, backup repositories, and containerized workloads all depend on shared storage — yet most IT organizations maintain a CMDB with zero storage-level configuration items.

Pure Storage FlashArray is one of the most widely deployed all-flash storage platforms in enterprise environments. IT teams choose it for its speed, simplicity, and the Purity//FA operating system, which exposes rich management data through a REST API, SSH-accessible CLI, and SNMP MIBs. Despite this, the FlashArray rarely appears in a CMDB.

This article explains why storage infrastructure is so commonly absent from the CMDB, what FlashArray data is worth capturing, how automated discovery works, and how to properly map storage relationships to other configuration items.

Why Storage Infrastructure Is Missing from Most CMDBs

Ask any IT Director about their CMDB and you will hear a consistent story: servers, virtual machines, and network devices are reasonably well-represented, but storage arrays are almost entirely absent.

Three root causes explain this gap.

1. Discovery Tools Default to Server-Centric Approaches

Most Pure Storage CMDB discovery tools start with IP scanning and agent-based server discovery. Storage arrays respond to ICMP and may appear as an IP address on a network scan, but without a purpose-built storage protocol handler, the tool collects only the management IP and hostname — no volumes, no controllers, no host mappings.

2. Storage Teams Own Separate Tools

Pure Storage ships with Pure1, its own cloud-based management platform. Storage administrators use it for performance monitoring, capacity planning, and troubleshooting. Because storage teams already have visibility, they rarely champion adding FlashArray data to the CMDB. The result is a silo: the CMDB team does not know what the storage team tracks, and the storage team does not see the value of CMDB integration.

3. Storage CIs Do Not Map Cleanly to Standard CI Classes

CMDB data models designed for servers and network devices do not naturally accommodate storage constructs like volumes, protection groups, and host-to-volume connections. Extending the CI schema requires work that many organizations defer indefinitely.

The consequence of this gap is significant. When an application team needs to understand which storage volumes back a production database cluster, they cannot get the answer from the CMDB. When a change manager evaluates the impact of a FlashArray firmware upgrade, they have no relationship data. When an auditor asks for an asset inventory, the storage fleet is invisible.

What Is Pure Storage FlashArray?

Pure Storage FlashArray is an all-flash storage array running the Purity//FA operating system. It provides block storage (iSCSI and Fibre Channel) and, in recent versions, unified file and object capabilities. Each FlashArray consists of:

• Dual controllers (CT0 and CT1): Active-active hardware controllers that handle all I/O. Each controller has its own CPU, memory, and network interfaces.
• Storage volumes: Logical units of storage allocated to hosts. Each volume has a name, size, WWN or IQN target identifier, and protection group membership.
• Hosts and host groups: Logical representations of compute systems connected to the array. A host is defined by its initiator identifiers (Fibre Channel WWNs or iSCSI IQNs).
• Protection groups: Collections of volumes managed together for snapshot and replication.
• Interfaces: Fibre Channel ports and Ethernet ports on each controller.

FlashArray models range from the entry-level FlashArray//C (capacity-optimized) to the performance-focused FlashArray//X and FlashArray//XL, and the newer FlashArray//E aimed at consolidating legacy spinning disk.

What Data Should You Capture in Your CMDB?

Not every piece of FlashArray data belongs in a CMDB. The CMDB is a configuration and relationship database, not a performance monitoring tool. The goal is to capture stable configuration attributes that support change management, impact analysis, and incident resolution.

Storage Array CI

Attribute	Value
Array Name	Administrator-defined
Serial Number	Factory-set identifier
Model	FlashArray//X70, FlashArray//C60, etc.
Purity//FA Version	Firmware version
Management IP	Array management interface address
Capacity (raw/effective)	Total and usable capacity

Controller CIs

Each FlashArray has two controllers (CT0 and CT1). Capturing controller-level CIs enables targeted troubleshooting when a specific controller generates alerts.

Attribute	Value
Controller Name	CT0 or CT1
Hardware Model	Controller SKU
Status	Online, offline, or degraded
Part Number	For hardware asset management

Volume CIs

Volumes are the most operationally relevant FlashArray CIs. They represent the storage allocations consumed by servers and applications.

Attribute	Value
Volume Name	Administrator-defined name
Size (GB)	Allocated capacity
WWN / IQN	Target identifier
Protection Group	Snapshot group membership
Connected Host	The host or host group mapped to this volume

Host CIs

Hosts in FlashArray represent connected compute systems. These should be correlated with server CIs in the CMDB to build the relationship: Server → connected to → FlashArray Volume → hosted on → FlashArray.

How Automated Discovery Works for FlashArray

FlashArray exposes management data through three mechanisms.

SSH-Based Discovery (Purity CLI)

FlashArray runs SSH on its management interfaces. An authenticated SSH session can query array status, controller details, volume lists, host mappings, and interface configurations using Purity//FA CLI commands:

• purearray list — Array name, serial number, firmware version
• purehw list — Hardware component inventory including controllers, fans, power supplies, and drives
• purevol list — All volumes with size and protection group
• purehost list — All defined hosts with initiator identifiers
• purehost list –connection — Volume-to-host mapping table
• purenetwork list — Management and replication network interfaces

SSH-based discovery provides the most complete picture because it accesses the Purity//FA CLI directly, returning structured output that a discovery agent can parse into CI attributes.

SNMP-Based Discovery

Pure Storage FlashArray supports SNMP v2c and v3. SNMP discovery can identify the array, retrieve system-level information (OIDs mapped to array model, serial number, and status), and receive SNMP traps for hardware alerts.

SNMP is best suited for initial network scanning to identify FlashArray management IPs and as a lightweight health-status feed. It is not sufficient for capturing volume and host relationship data, which requires CLI or API access.

REST API Discovery

Purity//FA exposes a comprehensive REST API (v1.x and v2.x). The API is the most structured way to retrieve FlashArray data at scale and is the preferred integration method for purpose-built CMDB discovery tools. API-based discovery uses an API token (not a password) and can enumerate arrays, volumes, hosts, connections, and interfaces in a single authenticated session.

Mapping FlashArray to CMDB Relationships

Capturing FlashArray data in isolation has limited value. The real CMDB benefit comes from relationship service mapping — connecting the storage CIs to the compute and application CIs that depend on them.

Key relationships to map:

• Server (host) uses FlashArray Volume
• FlashArray Volume is hosted on FlashArray Array
• FlashArray Controller is component of FlashArray Array
• FlashArray Array connects to Physical Switch (via FC or Ethernet)

These relationships support:

• Change impact analysis: When a FlashArray firmware upgrade is scheduled, the change manager can query which servers and applications are at risk.
• Incident correlation: When a volume reports I/O errors, the CMDB can identify which application CIs are affected.
• CMDB health reporting: Orphaned volumes (volumes with no host mapping) become visible as potential cost and security risks.

The most challenging relationship to maintain is the server-to-volume mapping, which changes as workloads are provisioned and decommissioned. Scheduled re-discovery at appropriate intervals — daily or weekly — keeps this data current without requiring manual updates.

Best Practices for Mapping Pure Storage FlashArray in Your CMDB

1. Use a Dedicated Read-Only Service Account

Create a FlashArray user with read-only access (readonly role) for CMDB discovery. Never use an administrator account for discovery. The read-only role supports all list and show commands without granting access to modify array configuration.

2. Scope the Discovery to CI Types That Matter

Not all array data belongs in the CMDB. Focus discovery on: the array itself, controllers, volumes (with capacity and host mapping), and hosts. Skip metrics, performance counters, and operational logs — those belong in monitoring tools.

3. Map Volumes to Servers Using Host Initiator Data

FlashArray host objects contain iSCSI IQNs or Fibre Channel WWNs that correspond to server HBA identifiers. Use these identifiers to correlate FlashArray host objects with server CIs already in your CMDB. This correlation creates the server-to-storage relationship without requiring a separate integration.

4. Schedule Regular Re-Discovery

Volume-to-host mappings change frequently in active environments. Set up automated re-discovery at least weekly to capture new provisioning activity, volume expansions, and decommissioned mappings.

5. Normalize Naming Conventions Before Importing

If your storage team uses inconsistent naming conventions for volumes, establish a standard and apply it before building CMDB relationships. Inconsistent names make correlation to application CIs much harder.

6. Reconcile Against Your Asset Management Record

Cross-reference discovered FlashArray controllers and expansion shelves with your hardware IT asset management records. Use the FlashArray serial number as the unique identifier for reconciliation to avoid duplicate or conflicting records.

Virima and Pure Storage FlashArray Discovery

Virima’s CMDB and IT discovery platform supports automated Pure Storage FlashArray discovery, introduced in version 6.1.1. Using SSH-based discovery, Virima enumerates FlashArray arrays, controllers, volumes, and host connections and populates these as native CIs in the Virima CMDB.

The discovery process uses a read-only service account and supports scheduled runs so volume-to-host mappings stay current as the storage environment changes. Discovered FlashArray CIs are automatically related to the server, and network CIs are identified through Virima’s broader multi-vendor discovery, enabling the relationship-based CMDB that IT teams need for change impact analysis and incident response.

Virima also integrates with ServiceNow, Jira, Ivanti, and other ITSM platforms, so FlashArray CIs discovered by Virima can be synchronized to the ITSM of your choice.

Conclusion

Pure Storage FlashArray is a critical piece of enterprise infrastructure that is consistently missing from the CMDB. The data is accessible — through SSH, SNMP, or REST API — but most organizations lack a discovery process that covers storage infrastructure alongside servers and network devices.

Getting FlashArray into your CMDB is an ongoing operational process, not a one-time project. It requires a repeatable discovery workflow, a clear CI schema for storage objects, and relationship mappings that connect volumes to the servers and applications that depend on them. When those three pieces are in place, the CMDB becomes genuinely useful for change management, incident response, and capacity planning.

Ready to see how Virima discovers Pure Storage FlashArray and your full IT infrastructure automatically? Schedule a demo at virima.com.