Is DSE pool mandatory on VMAX3 for Snapvx?

Helo Samir,

Dynamox is right

from snapvx manual

SnapVX creates snapshots by storing changed tracks (deltas)

directly in the Storage Resource Pool (SRP) of the source device.

Hi Samir,  DSE as in Delta Set Extensions?  If so, DSE's are used for remote replication, whereas SnapVX is used for local replication. DSE used by SRDF/A if delta sets cannot be shipped from the source array (R1) to the target array (R2), for instance the telco network went down then, the delta sets would be put into a "DSE Pool" made up of special SAVE devices.  When the telco link came back online the delta sets would be shipped over to the R2 side.  The underlined statement is NOT applicable to VMAX3, as it simply uses capacity from the SRP for it's DSE capacity.

I suspect you may be familiar with a previous version of TimeFinder, and that's the context of your question?  You may be thinking of the way things used to work on VMAX2 & prior. TimeFinder Snap allowed a user to make a thin pointer based copy of a thick (traditional) source LUN.  The copy wasn't really a copy at all but a virtual device or "VDEV", that was host addressable on the front end and pointed to the tracks on the thick source LUN, at the point in time the Snap was made.  When a Snap was active, any writes to it (VDEV) from a secondary host and any writes to the source LUN, wrote to a pool of storage made up of SAVE devices, which were back end, non-host addressable devices (kind of like private LUNs).

Later when Virtual Provisioning came out, all volumes were thin (source and copies).  So a thin snap of a thin source used something new at the time called VP-Snap. Some customers wanted their writes for the Snap going to a different pool than the the source LUN's pool. Therefor VP-Snap supported separate pools but it wasn't a requirement.