VMAX already provides the highest availability of any enterprise storage array in the market with the built for purpose design that includes more reliability availability and serviceability features than you can shake a stick at you can read all about it in here https://www.emc.com/collateral/technical-documentation/h13807-emc-vmax3-reliability-availability-and-serviceability-tech….  In addition to the designed in features of the hardware and microcode, VMAX systems provide the Enterprise Data Services which give an extra layer of protection should a band or rebels happen to attack your base, or more likely someone makes a mistake and we need to roll back to an earlier copy of your data..You know what they say, everybody makes mistakes that's why they put erasers on pencils!. 


With VMAX3 our Snapshot offering was completely overhauled and SnapVX was born, there is an really good paper on that too https://www.emc.com/collateral/technical-documentation/h13697-emc-vmax3-local-replication.pdf. This post will take you through how you can leverage Unisphere for VMAX's REST API to take snapshots of your data and automate some of the tasks to help you access the snapshot should you need to mount it for DevOps QA/Test or even cosmetic restores.  We'll also look at how to restore from a snapshot.  To follow the examples I outline here I would recommend that you have at least read my previous post on Getting Started with REST the link is below.  It's also assumed you have some basic knowledge of SnapVX snapshots and the process of linking, relinking, unlinking to a target storage group.

Getting Started with VMAX REST API

OK, so just like before the REST Client or the Documentation can be used to help identify the endpoints we need to create our script.   The great thing about SnapVX with Unisphere is that it's built around the storage group so we don't need to manage additional containers such as device groups or device files,  this makes management a lot easier as we already have a storage group container which we use for provisioning our application so if we want to snapshot the same application we can use what already exists..

All of the endpoints for SnapVX are under /replication/symmetrix/{symmetrixId}/storagegroup/{storageGroupId}/snapshot for the examples I will be using the Unisphere 8.3 endpoints as they provide more automation features that I would like to leverage later on also utilizing the latest endpoint in the REST interface lets me know what version I have tested with and also exposes the latest features.

Creating a Snapshot is probably the simplest script you can create, you only need to make a single call.

/83/replication/symmetrix/{symmetrixId}/storagegroup/{storageGroupId}/snapshot because we are creating a new object this will be a POST call, and we need to provide a payload.  The Payload is very simple so I have pasted here.  We provide a snapshot name and optionally the time to live.


  "snapshotName": "REST_Test",

  "daysToLive": 1



I recommend always specifying a time to live value, as the longer snapshots stay around the more resources they will consume,  while we are very efficient nothing is ever free, plus if you are thinking about using for a restore purpose you probably will have a minimum Recovery Point Objective that is acceptable to your business or customers.  This is all discussed in depth in the technote mentioned earlier.  Optionally you can also specify to take a snapshot on bothsides if the volumes are remotely replicated in synchronous or metro mode, this means that you have the same snapshot data on both sides and if disaster strikes and you have corruption you will have snapshots that you can restore from at either site.  Now tell me that's not pretty cool

For those who have followed my previous post in this series, you will know that we have a GitHub with a number of functioning methods/functions that you can leverage to build your own custom scripts. I've also posted some example scripts, the file LocalReplication.py gives a simple example of how this could be leveraged in Python.

I've coded the example to automatically set the snap name based on the current date and time when the snap is taken.  This is an example only but make thing really simple to code as there will only ever be one generation of a snap with a specific name also the name makes it immediately obvious when the snap was taken without having to make multiple calls.  Also I'm using the config file to set my unisphere server and IP address as outlined in episode 1.


GitHub - ciarams87/PyU4V: A library showing some of the functionality possible using the ReST API of UniSphere for VMAX

As always feel free to clone and contribute to the Git Hub, This is a relatively short script so I will post the full code example here.

The source code is available on the GiT, As you can see this example is pretty short,  pass in the storage group name and a snapshot is created.  It's calling the function create_sg_snapshot83 from the PyU4V library of scripts discussed back in episode 1. 

Next we'll get a bit more detailed. 

So, we've created a Snapshot the next thing you might want to do is access it..  Notice we didn't need any additional volumes to create our snapshots, they are targetless so very efficient, the only time we need additional volumes is to access the snapshot. 

This is actually pretty simple to do but there are a few steps, there would be a lot more but through the magic of Unisphere and the ease of REST it's not as hard as it would seem.  Unisphere has the ability to create a target storage group on the fly so we can utilize the REST call to automate this, so we don't need to look at each individual volume and create a target device of the correct size Unisphere will do that for us and we can do the same through REST.  This is one of the advantages of using REST, we can do all these things leveraging the smarts built into unisphere, if we were to do this with a CLI script it would be multiple commands. 

In REST this will be one call to create the link, and then another call to access the snapshot creating the masking view.  I'm going to use an additional call to list the available snapshots for my storage group so I can choose the one I want.  If you already know you can script it this way too.

/83/replication/symmetrix/{symmetrixId}/storagegroup/{storageGroupId}/snapshot - Get Method To find a list of SnapShots


The Next call will do all the heavy lifting, creating devices if necessary.  If your target storage group is already part of a masking view, then you only need to have these two calls in your script.


/83/replication/symmetrix/{symmetrixId}/storagegroup/{storageGroupId}/snapshot/{snapshotId}/generation/{generationNumber} PUT Method with a small Payload


  "link": {

    "linkStorageGroupName": "REST_TEST_LNK01_SG"


  "action": "Link"



If you need to mask we can create a masking view similar to episode 1 : provisioning.  In this case I will simplify assuming that the mount host already exists so we can use existing components.

/provisioning/symmetrix/{symmetrixId}/maskingview  - This is a POST call with a payload containing the SGNAME, Host Name, Port Group

Below is the sample JSON payload.


  "portGroupSelection": {

    "useExistingPortGroupParam": {

      "portGroupId": "REST_TEST_PG"



  "maskingViewId": "REST_LNK_SNAP_MV",

  "hostOrHostGroupSelection": {

    "useExistingHostParam": {

      "hostId": "REST_TEST_IG"



  "storageGroupSelection": {

    "useExistingStorageGroupParam": {

      "storageGroupId": "REST_TEST_LNK01_SG"




I'm going to put all that together in an little python program again now,  and will share that on GiT.   

Other actions you may want to take with REST on snapshots are restore, relink and terminate  you can explore these in the REST Client and in the guide,  Obviously you want to take care with RESTORE as you will be overwriting the source data.  So maybe this is not one you would script.


Some Sample code has been added to the Git, so the missing link is up there.  Timeout issue has been addressed in rest_requests.  A more robust fix will be in Unisphere Version 8.4 which is on it's way.  The script is very short but does a lot, the main guts as always have been added to rest_univmax.py.





Stay Tuned for Episode 3.  Return of the SRDF