IBM Support

PureApplication System v2 “snapshot” Management and Best Practices

Technical Blog Post


PureApplication System v2 “snapshot” Management and Best Practices



The snapshot feature in PureApplication System provides the ability to save a copy of the entire state of a Virtual System so you can revert it back to the previous state if desired.  A snapshot is intended for use as a restore point if a problem occurs during a planned update to a virtual system instance, such as a maintenance update.  

I especially find this feature useful when I am applying WebSphere Application Server fixpack updates to my test environment and want to ensure I can easily back out any changes. This allows me the opportunity to perform repeated tests quickly on the same instance.  Furthermore, If I am updating a production virtual system and run into a problem, I can restore the production instance within minutes, not hours.

It also helps that snapshots are so easy to create, delete, recreate or restore as needed.  All it takes is a simple click of a button from the virtual system in the PureApplication UI.  Now that is what I call convenience!

By default, a snapshot is automatically created when applying maintenance to virtual systems using the instance console.  Starting in V2.0.0.0 cfix1, you can disable this automation if desired by clicking on the "Disable Automatic Snapshots" button.   For virtual systems (classic) a snapshot is not automatically created but if desired, you have the option to select the check box that states "Take a snapshot before service is applied" from the service panel.







Note:  You can take only one snapshot of the instance and the restore button will not appear until the snapshot is created. 

Did you know that snapshots can also be managed using REST APIs?

Did you also know that W1500 & W2500 PureApplication Systems use 1.8 TB datastores? Creating a snapshot of a virtual system instance creates snapshots of the VMs on the same 1.8 TB datastore(s) used by the VMs and will take up the exact size of each VM.  For example, if the VM is 50 GB then the snapshot will also take up 50 GB. So if you are taking a snapshot for a pattern containing 5 VMs with 50 GB each, then you will need 250 GB to be free on the datastore(s) to hold the snapshots of all the VMs associated with that virtual system instance. Currently, there is no way to configure an alternate location for snapshots.  W1700 and W2700 PureApplication Systems do not have datastores and the VM allocations are done on actual LUNs in the Storwize V7000. On these systems a new LUN is created on the Storwize V7000 when creating a snapshot and therefore space capacity is less likely to be a factor.


If you are unable to create (generate) a snapshot due to insufficient free capacity on a datastore, there are couple remedies to help resolve the issue.



First, to confirm you are encountering this issue I suggest searching the workload trace.log or checking the snapshot job details for the following error:

CWZIP2437E The requested storage_volume does not have enough free capacity for the volume.            

The trace.log is available from Workload Console --> System --> Troubleshooting and starting in v2.1 it is available from System --> Workload Troubleshooting.  The snapshot job details can be viewed from System Console --> System --> Job Queue and in v2.1 System --> Job Queue.

Next, you can identify the datastore and verify it’s Free Capacity using the following 8 steps:

1. click on one of the virtual machines for the virtual systems instance under Workload Console > Instances > Virtual Machines

2. look at the console URL to find the virtual machine instance id ie:


52b9ddef-90f0-4778-9fe2-d5cef08bd83c is the virtual machine instance id

3. issue REST API:


4. look up the disks entry ie:





5. using the same disks example above, issue REST API:


6. look at the storage volumes entry ie:

storage_volumes: "63bacea8-d89f-4b83-bf3d-9b71d6232e5c"

7. issue storage_volume_placements REST API:


8. finally scroll down to verify the available Free Capacity of this datastore

"free_capacity": 13795,

"capacity": 1887436,

"free_capacity" Is in MBs

Note: for step 4 (above): If multiple disk entries are shown, then repeat steps 5 & 6 for each disk.  If the storage_volumes entry in step 6 is different for each of the disks, then repeat steps 7 & 8 for each datastore volume to check free capacity.

To free up space on the datastore(s), we recommend deleting any old snapshots that are no longer needed. This is the fastest and easiest way to free up space.  To get started, you can view all existing snapshots on the rack by looking at REST API output:


example snapshot REST output:


created_time"Tue 13 Jan 2015 10:13:50.990 UTC",


description"Created by {name}",




jobs: [ ],


label_text"Instance Snapshot",

name"Generated Snapshot",




updated_time"Tue 13 Jan 2015 10:14:01.039 UTC",





d985bc14-db54-466d-8689-f7f9abecb9c9 is the instance snapshot id

d3d9c4ec-dd0c-4172-bb84-bca43a17b71d is the virtual machine instance id

To delete a snapshot, issue a REST DELETE on the instance snapshot id ie:


Note: You must be granted access to the virtual system instance or have the Workload resources administration with Full permission role to complete this task.

In general snapshots are not intended for long-term use and it is recommended you delete them after you have completed your maintenance updates. This is a snapshot management Best Practice and can help avoid hitting free capacity issues from the start.

If deleting old snapshots does not free up enough space on the datastore(s), then you may want to consider deleting old VMs (that are no longer needed) on the same datastore to help free up additional space.


Additional Resources:



title image (modified) credit: (cc) Some rights reserved by ClkerFreeVectorImages


[{"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":""}]