VMAX3 and PowerMax are both enterprise storage arrays developed by Dell EMC (formerly

EMC), designed for mission-critical workloads. However, PowerMax is the newer generation
that builds upon and replaces VMAX3, bringing significant architectural and performance
enhancements.

Below is a detailed comparison of VMAX3 and PowerMax storage arrays:

Architecture

Feature VMAX3 PowerMax

4th and 5th Generation (PowerMax

Generation 3rd Generation
2000/8000, PowerMaxOS)

Storage VMAX3 engine with separate front- Integrated "active-active" architecture

Engine end, back-end, and cache with all-NVMe design

Media End-to-end NVMe (SSD/NVMe), SCM

SAS HDDs, SSDs (Flash), eMLC
Support (Storage Class Memory - Optane)

Disk-array enclosures with Smaller footprint, higher density, NVMe

Form Factor
directors drives

Performance and Scalability

Feature VMAX3 PowerMax

Max IOPS Millions (varies by model) Up to 15M+ IOPS

Latency ~Sub-millisecond ~100 microseconds with SCM

Up to 384 drives (depending on Over 1,000 NVMe drives (PowerMax

Scalability
model) 8000)

Bandwidth Lower compared to PowerMax Much higher throughput per engine

Intelligence & Automation

Feature VMAX3 PowerMax

Data Manual or limited automated Real-time machine learning for data

Placement tiering (FAST) placement (built-in AI engine)
Feature VMAX3 PowerMax

FAST.X, Service Level Full SLO-based provisioning with AI

Automation
Objectives (SLOs) optimization

Unisphere for PowerMax, REST APIs,

Management Unisphere for VMAX
Ansible, CSI driver

Data Services

Feature VMAX3 PowerMax

Same, but with faster operations and lower

Replication SRDF, TimeFinder
RPOs

Encryption Optional Always-on inline encryption

Inline deduplication and compression

Deduplication/Compression Compression only
(more efficient)

TimeFinder Enhanced SnapVX (more scalable and

Snapshots
SnapVX performant)

Protocols & Ecosystem

Feature VMAX3 PowerMax

Protocol Support FC, iSCSI, FICON Same, plus NVMe-oF (NVMe over Fabrics)

Mainframe
Yes Yes, with better performance
Support

Cloud Basic Native integration with AWS, Azure, GCP (Cloud

Integration (CloudArray) Mobility, Data Protection)

Software and OS

Feature VMAX3 PowerMax

Operating System HyperMax OS PowerMaxOS

Feature VMAX3 PowerMax

File Support eNAS (separate) No native file support (block only)

Container Support Limited CSI driver, Kubernetes support

Lifecycle & Support

Feature VMAX3 PowerMax

Release Year 2014 2018+ (continuously evolving)

Support End-of-sale; nearing end-of-

Fully supported; active development
Status support

Migration Direct upgrade paths within PowerMax

Requires data migration
Path family

Summary

Aspect VMAX3 PowerMax

Performance Good Excellent (NVMe & SCM)

Efficiency Moderate High (inline dedupe, compression)

Automation Basic AI-driven

Future-proof Outdated Current and evolving

When to choose PowerMax over VMAX3?

• If you need extremely low latency and high throughput

• If you're modernizing to NVMe, SCM, or cloud-integrated workflows

• For better data reduction, inline encryption, and AI automation

• To align with next-gen applications (AI/ML, containers, high-performance DBs)

Allocation Procedure:

The PowerMax allocation procedure refers to the steps used to provision storage volumes
from a Dell EMC PowerMax array to hosts (servers). PowerMax simplifies and automates
much of the allocation process using Service Level Objectives (SLOs) and intelligent
automation features built into PowerMaxOS.

Below is a clear and detailed procedure for allocating storage from a PowerMax system.

PowerMax Storage Allocation Procedure

1. Plan the Storage Requirements

Before allocating storage:

• Identify host requirements (OS, application, size, performance).

• Choose:

o Volume size(s)

o Number of volumes

o Protocol (Fibre Channel, iSCSI, NVMe-oF)

o SLO (Gold, Silver, Bronze, etc.)

2. Create a Storage Group (SG)

A Storage Group is a container for volumes that share the same service level and policies.

Via Unisphere GUI:

• Go to Storage Groups → Create.

• Assign a name (e.g., SG_APP01).

• Add volumes now or later.

Via CLI (Solutions Enabler):

symaccess -sid <SID> create -type storage -name SG_APP01

3. Create Volumes
PowerMax supports thin provisioning (volumes are created logically, not physically allocated
until written to).

Via Unisphere:

• Choose size, quantity, and format (e.g., TDEV).

• Add to your SG.

CLI Example:

symconfigure -sid <SID> -cmd "create dev count=10, size=100GB, emulation=FBA,

config=TDEV;" commit

4. Add Volumes to the Storage Group

Via Unisphere:

• Navigate to the SG → “Add Volumes” → select or create.

CLI:

symaccess -sid <SID> -name SG_APP01 -type storage add devs 0001,0002

5. Apply a Service Level (SLO) and Workload Type

Service Levels manage performance and QoS (Gold, Silver, Bronze, etc.)

Via Unisphere:

• Go to the SG → Edit SLO.

• Select an SLO and workload type (OLTP, DSS, etc.).

CLI:

symsg -sid <SID> set -sg SG_APP01 -sl Silver -wl OLTP

6. Map Volumes to a Masking View

A Masking View (MV) connects the SG to:

• A Host Initiator Group (IG)

• A Port Group (PG)

Steps:
A. Create Initiator Group (IG)

For FC, this includes WWNs of the host HBA ports.

symaccess -sid <SID> create -type initiator -name IG_APP01 -wwn 10000090fa2d1234

B. Create Port Group (PG)

Include front-end ports to be used.

symaccess -sid <SID> create -type port -name PG_APP01 -dirport 4e:0, 4f:0

C. Create the Masking View

Connect the SG, IG, and PG.

symaccess -sid <SID> create view -name MV_APP01 -sg SG_APP01 -ig IG_APP01 -pg
PG_APP01

7. Host Discovery and OS Configuration

• Rescan host HBAs (using rescan-scsi-bus, echo in /sys, or Windows Disk

Management).

• Create partitions, filesystems, or multipathing configurations (MPIO).

• Optionally label or mount the LUNs.

Tips and Best Practices

Tip Description

Let PowerMax automatically place data based on performance

Use SLOs
tier

Use Consistent Naming SG, IG, PG, MV names should be clear and standardized

Enable Masking Only mapped hosts should see volumes

Monitor Workloads Use Unisphere or REST API to track performance and alerts

Reclaim Unused
Unused TDEVs can be deleted or repurposed easily
Volumes
SRDF procedure:

SRDF (Symmetrix Remote Data Facility) is Dell EMC’s remote replication solution for
PowerMax and VMAX storage arrays. It allows you to replicate data between arrays over
distances for disaster recovery, high availability, and data mobility.

There are different modes of SRDF replication:

• SRDF/S (Synchronous)

• SRDF/A (Asynchronous)

• SRDF/DM (Data Mobility)

• SRDF/Metro (for active-active data centers)

SRDF Procedure with Example (PowerMax)

Scenario:

We will configure SRDF/Synchronous (SRDF/S) between two PowerMax arrays:

• Source (R1): Array_A (SID: 000197800123)

• Target (R2): Array_B (SID: 000197800456)

• 2 devices on each side: DEV001, DEV002

Pre-requisites:

• SRDF licenses installed on both arrays

• Connectivity (fiber or IP) established

• RDF groups configured

• Devices created and RDF-paired

Step-by-Step SRDF Procedure

Step 1: Create RDF Group (if not already created)

symrdf -sid 000197800123 -rdfg 5 createpair -file [Link] -type RDF1 -establish

You need a group defined on both sides (rdfg 5 here is an example RDF group ID).
 Step 2: Prepare Device Pairs File

[Link]:

DEV001 DEV101

DEV002 DEV102

• DEV001 and DEV002: source devices (R1)

• DEV101 and DEV102: target devices (R2)

• These should be mapped and masked appropriately.

Step 3: Create SRDF Device Pairs

symrdf -sid 000197800123 -rdfg 5 -file [Link] createpair -type RDF1

This command will:

• Define the R1 and R2 pairs

• Set up metadata on both arrays

Step 4: Verify Device Pair Status

symrdf -sid 000197800123 -rdfg 5 query

Look for:

• R1 devices in "WD" (Write Disabled) state

• Pair status: Not Ready / Synchronized

Step 5: Establish the SRDF Session (Start Sync)

symrdf -sid 000197800123 -rdfg 5 -file [Link] establish

This command starts synchronization from R1 to R2.

Step 6: Monitor Sync Progress

symrdf -sid 000197800123 -rdfg 5 -file [Link] query

Look for:

• Pair status: Synchronized

 • R2 state: Ready

Step 7: Optional — Set Device Modes (Optional Tuning)

You can set consistency, mode, etc.:

symrdf -sid 000197800123 -rdfg 5 -file [Link] set mode sync

Step 8: SRDF Failover (Planned)

For planned failover to R2:

1. Make R1 devices not ready:

symrdf -sid 000197800123 -rdfg 5 -file [Link] suspend

2. Make R2 devices writable:

symrdf -sid 000197800456 -rdfg 5 -file [Link] failover

symrdf -sid 000197800456 -rdfg 5 -file [Link] rw enable

Step 9: Restore Normal Operations (Failback)

To return to R1:

symrdf -sid 000197800456 -rdfg 5 -file [Link] suspend

symrdf -sid 000197800123 -rdfg 5 -file [Link] failover

symrdf -sid 000197800123 -rdfg 5 -file [Link] rw enable

symrdf -sid 000197800123 -rdfg 5 -file [Link] establish

Notes

• Use symdev list and symrdf query frequently to monitor states.

• Ensure zoning and masking are correct.

• Automate with scripts if you have many devices.

Useful Commands Reference

Command Purpose

symrdf -sid <sid> -rdfg <id> query Show SRDF device status

symrdf -sid <sid> -rdfg <id> -file <file> createpair Create device pairs

symrdf -sid <sid> -rdfg <id> -file <file> establish Start sync

symrdf -sid <sid> -rdfg <id> -file <file> failover Perform failover

symrdf -sid <sid> -rdfg <id> -file <file> suspend Suspend SRDF link

symrdf -sid <sid> -rdfg <id> -file <file> rw enable Make R2 devices writable
Local Replication :

PowerMax local replication is typically performed using TimeFinder technologies. The most
commonly used local replication methods on PowerMax are:

• TimeFinder SnapVX (Snap-based replication)

• TimeFinder Clone (full-copy replication — less used today)

• TimeFinder VP Snap (deprecated in newer arrays)

The modern, recommended method is SnapVX.

What is SnapVX?

SnapVX creates space-efficient, pointer-based snapshots of volumes. These snapshots are

managed via “snapsets” and can be accessed via linked target devices for read/write testing
or backup operations.

SnapVX Local Replication – Step-by-Step Procedure

Scenario

• Source Device(s): 0001, 0002 (LUNs on PowerMax)

• You want to take a local snapshot of these devices.

• You will optionally link them to target devices (0011, 0012) for access.

Tools Used

• Solutions Enabler CLI (e.g., symcli)

• SID of array: 000197800123

Step-by-Step SnapVX Example

Step 1: Create a SnapVX Snapshot

symdev -sid 000197800123 -g my_dev_group snapvx create -name SNAP_2809

 • my_dev_group: device group with source devices (0001, 0002)

• SNAP_2809: name of the snapshot

You can also use a device list instead of a group:

symdev -sid 000197800123 list -dev 0001:0002 snapvx create -name SNAP_2809

Step 2: Verify the Snapshot

symdev -sid 000197800123 show 0001

Look for Snapshot Name: SNAP_2809 under SnapVX info.

Or list all snapshots:

symsnapvx -sid 000197800123 list

Step 3: Link Snapshot to Target Devices (Optional)

You can link the snapshot to target devices for access (read/write or read-only).

symdev -sid 000197800123 -g my_dev_group snapvx link -name SNAP_2809 -target

my_target_group

• my_target_group: contains 0011, 0012 (must be same size as source)

• Linked targets can be mounted on a host for testing or backup

To make target read/write (optional):

symdev -sid 000197800123 -g my_target_group write_enable

Step 4: Unlink Snapshot from Target Devices

symdev -sid 000197800123 -g my_dev_group snapvx unlink -target my_target_group

This safely detaches the snapshot from the target volumes.

Step 5: Delete the Snapshot (When No Longer Needed)

symdev -sid 000197800123 -g my_dev_group snapvx terminate -name SNAP_2809

This will remove the snapshot. If it's still linked, you’ll get an error.
 Step 6: Restore from Snapshot (Optional)

If you want to restore the original device from the snapshot:

symdev -sid 000197800123 -g my_dev_group snapvx restore -name SNAP_2809

Use -invalidate to make snapshot data active and invalidate current data.

Commonly Used Commands

Command Description

symdev snapvx create Create a snapshot

symdev snapvx link Link snapshot to target devices

symdev snapvx unlink Unlink target devices

symdev snapvx restore Restore from snapshot

symdev snapvx terminate Delete the snapshot

Decommission Procedure:

Below is a generalized / reference-level procedure for decommissioning (or removing) a

Masking configuration / Masking Views in a Dell PowerMax (or VMAX) environment. The
exact steps may vary depending on your software version, environment (e.g. whether RAID
groups, replication, encryption, etc. are involved), and your internal policies. Use this as a
guideline and validate via Dell documentation or your storage team.

Background & Concepts (to keep in mind)

Before decommissioning masking, it helps to understand how PowerMax masking works:

• A Masking View (MV) ties together three elements: a Storage Group (SG), an
Initiator (Host) Group (IG) or host/host-group, and a Port Group (PG). Dell+2Dell
Technologies Info Hub+2

• When a masking view is deleted, hosts lose access (visibility) to the devices in that SG
via the defined ports/initiators.

• You cannot have a masking view with an empty storage group (i.e. SG must have at
least one device) Dell Technologies Info Hub+1

• Some environments may have dependencies like replication (SRDF), snapshots, or

encryption. These must be addressed prior to decommissioning masking.

• For Data-at-Rest Encryption (D@RE), decommission involves wiping keys, etc. Dell
Technologies Info Hub

High-Level Steps for Masking Decommission

Below is a typical sequence of steps to decommission a masking view / mask configuration:

Step Description Notes / Cautions

Identify exactly which masking

views, storage groups, initiator
Always export or backup your current
groups, port groups are to be
masking configuration (e.g. via
1. Plan & Validate removed. Ensure no
symaccess list view -all -v -detail) for
production I/O traffic is active
audit or rollback.
or that host access is
quiesced.
Step Description Notes / Cautions

On the host side, unmount or

2. Quiesce I/O / offline the volumes or stop Risk of data corruption if you remove
Stop Host Access I/O. Ensure that no process is the mask while I/O is ongoing.
actively using the LUNs.

This removes the link between SG, IG,

Use symaccess delete view
PG and effectively unmaps/unmasks;
3. Delete / Remove <view_name> (or via
devices become invisible to hosts. Dell
Masking View (MV) Unisphere or REST API) to
Technologies Info Hub+4SAN-
remove the masking view.
Engineer+4Dell+4

If the storage group is no

4. (Optional) Delete longer needed, delete it: Be careful — only do this if no other
/ Clean Up Storage symaccess delete -name masking view or replication uses the
Group <sg_name> -type storage - SG. SAN-Engineer
force (or via GUI).

5. Delete / Clean
If the initiator group is no Similar caution: ensure no other MVs
Up Initiator Group
longer needed, remove it. depend on it.
(Host / Host Group)

6. Delete / Clean Remove port group if not used

Check dependency.
Up Port Group elsewhere.

On the host, rescan the

7. Host Rescan / FC/HBA paths and update
Helps clean up residual paths.
Multipath Cleanup multipathing so that stale
paths are removed.

Dell’s decommission of a PowerMax

8. Address If the devices were under system (with D@RE) includes: running
Encryption / Key Data-at-Rest Encryption, a decommission script, securely
Wiping (if ensure the keys are wiped, deleting persistent key copies, zeroing
applicable) system caches cleared, etc. cached keys, generating a certificate of
deletion. Dell Technologies Info Hub

Document what was removed,

9. Documentation take screenshots, logs,
Useful for compliance and recovery.
& Audit certificate of deletion (if
encryption involved), etc.
Example / Commands (CLI / Symmetrix-style)

This is illustrative; adjust commands for your version or method (Unisphere, REST, CLI):

# Example: export current masking views

symaccess -sid <ArrayID> list view -all -v -detail > masking_backup.txt

# Delete a masking view

symaccess -sid <ArrayID> delete view <masking_view_name>

# If SG is no longer needed

symaccess -sid <ArrayID> delete -name <SG_name> -type storage -force

# On host: rescan FC, multipath rescan / cleanup

# e.g. on Linux:

echo "- - -" > /sys/class/scsi_host/hostX/scan

multipath -r

If you are using Unisphere, you would typically navigate through GUI:

• Go to Masking Views → select the view → Delete / Remove

• Then go to Storage Groups, Host Groups / Initiators, Port Groups and remove unused
ones

• Finally, in the host OS, do a rescan of storage and cleanup of paths

If using REST API, the call to delete a masking view would be via the maskingview endpoint
with state=absent semantics. Dell+1

Considerations & Pitfalls

• Ensure that no host or application is still dependent on the volumes.

• If the SG still has devices and you delete it without cleaning up, you may leave
“orphaned” volumes.

• If replication (SRDF / TimeFinder) is configured, disable or reconcile replication

before deleting masking.
 • If encryption is involved, you must follow the key deletion and wiping procedures;
failure to do so may leave residual data exposure or make audit trails invalid. Dell
Technologies Info Hub

• Be cautious about deleting common port/initiator groups that may be shared among
different masking views.

If you like, I can tailor a step-by-step decommissioning playbook specifically for your
PowerMax model / software version (e.g. PowerMax OS 10, or whatever version you have).
Do you want me to prepare that for your environment?

You said:

with example

ChatGPT said:

Here's a step-by-step PowerMax Masking Decommission Procedure with concrete

examples, assuming you're using Unisphere for PowerMax or the Solutions Enabler CLI
(symaccess).

Assumptions for the Example

Element Example Name

Masking View MV_APP01

Storage Group SG_APP01

Port Group PG_FC01

Initiator Group IG_APP01

Array ID 000197800123

Host OS Linux (rescan examples use Linux syntax)

Tools Used symaccess CLI (Solutions Enabler)

Step-by-Step Masking Decommission Procedure with Examples

Step 1: Backup Current Masking Configuration

symaccess -sid 000197800123 list view -all -v -detail > /tmp/masking_config_backup.txt

 This captures the full masking view setup so you can audit or restore later.

Step 2: Quiesce I/O and Unmount Volumes

On the host:

umount /mnt/app01_data

Stop any applications using the volumes. If you use clusterware (e.g., VCS, Pacemaker), place
the resource group in maintenance/offline mode.

Step 3: Delete the Masking View

symaccess -sid 000197800123 delete view MV_APP01

This removes the mapping between host and volumes via the storage group.

Step 4: Delete the Storage Group (Optional)

Only do this if the storage group is no longer needed and has no volumes or replication.

symaccess -sid 000197800123 delete -name SG_APP01 -type storage -force

You must first remove all devices from the SG before this works:

symaccess -sid 000197800123 -name SG_APP01 -type storage remove devs 0001A-0001F

Step 5: Delete Initiator Group (Optional)

symaccess -sid 000197800123 delete -name IG_APP01 -type initiator

Only if it's not used in other masking views.

Step 6: Delete Port Group (Optional)

symaccess -sid 000197800123 delete -name PG_FC01 -type port

Only if unused by any other masking view.

Step 7: Host Rescan / Cleanup Stale Devices

On the Linux host:

echo "- - -" > /sys/class/scsi_host/host0/scan

echo "- - -" > /sys/class/scsi_host/host1/scan

multipath -r

Remove stale devices if needed:

multipath -F

Step 8: (Optional) Handle Encrypted Devices

If you’re using Data at Rest Encryption (D@RE):

• Ensure volumes are securely deleted (symdev delete, or via GUI)

• Securely delete keys:

symecrypt -sid 000197800123 delete key -sg SG_APP01

• Zero cached key memory (requires proper privileges)

• Download Certificate of Deletion via Unisphere (if needed for audit)

Step 9: Document Changes

Keep a log of:

• Commands run

• Timestamp of decommission

• Masking views removed

• Devices unexported

• Certificate of Deletion (if encryption involved)

Example:

[2025-09-28 14:00] MV_APP01 deleted

[2025-09-28 14:05] SG_APP01 deleted

[2025-09-28 14:10] IG_APP01 and PG_FC01 deleted

[2025-09-28 14:20] Host rescanned - /dev/mapper paths removed

Summary of Key Commands

Task Command

Delete Masking View symaccess delete view <MV>

Delete SG symaccess delete -name <SG> -type storage -force

Delete IG symaccess delete -name <IG> -type initiator

Delete PG symaccess delete -name <PG> -type port

Host Rescan (Linux) echo "- - -" > /sys/class/scsi_host/hostX/scan

Remove Devices from symaccess -sid <SID> -name <SG> -type storage remove devs
SG <range>