PowerProtect Data Manager Deployment Automation – Deploy PowerProtect Data Manager in Minutes
Mon, 18 Sep 2023 22:34:52 -0000
|Read Time: 0 minutes
In the spirit of automating EVERYTHING, this blog will showcase the complete deployment of PowerProtect Data Manager (PPDM).
In the PPDM universe, we have auto-policy creation and ad-hoc VM backup solutions, use-case driven tasks, and so on -- all available in the official PowerProtect Data Manager GitHub repository. And now, I am proud to present to you the complete PPDM deployment automation solution.
Without further ado, let’s get started.
What does the solution do?
The PowerProtect Data Manager automated deployment solution boasts a wide array of functionality, including:
- Automatically provisioning PPDM from OVA
- Automatically deploying and configuring PPDM based on a JSON configuration file
- Adding PowerProtect DD (optional)
- Registering vCenter (optional)
- Registering remote PPDM systems (optional)
- Configuring bi-directional replication between two PPDM systems (optional)
What is the solution?
It’s a Python-based script that operates in conjunction with the PPDM REST API and vCenter.
Here is the list of prerequisites:
- Python 3.x (The script supports every platform Python is supported on)
- Python requests module, which can be installed using pip with the command: “pip install requests” or “python -m pip install requests”
- PowerProtect Data Manager 19.14 and later
- Connectivity from the host running the script to vCenter and PPDM
- PowerProtect Data Manager OVA image located on the host that is running the script
- Ovftool installed on the same host the script is running on
- Connectivity to remote PPDM system from the host running the script (only if the -ppdm parameter is provided)
How do I use the script?
The script accepts one mandatory parameter, -configfile or --config-file, and six optional parameters:
- (1) justova to deploy only the PPDM OVA or (2) skipova to skip OVA deployment
- (3) vc and (4) dd to register vCenter and PowerProtect DD respectively
- (5) ppdm and (6) cross to configure a remote PPDM system and bi-directional communication between the two PPDM systems respectively
- -cross / --bi-directional requires the argument -ppdm / --connect-ppdm to be specified as well
Here is the full script syntax:
# ppdm_deploy.py -h
usage: ppdm_deploy.py [-h] -configfile CONFIGFILE [-skipova] [-justova] [-vc] [-dd] [-ppdm] [-cross]
Script to automate PowerProtect Data Manager deployment
options:
-h, --help show this help message and exit
-configfile CONFIGFILE, --config-file CONFIGFILE
Full path to the JSON config file
-skipova, --skip-ova Optionally skips OVA deployment
-justova, --just-ova Optionally stops after OVA deployment
-vc, --register-vcenter
Optionally registers vCenter in PPDM
-dd, --add-dd Optionally adds PowerProtect DD to PPDM
-ppdm, --connect-ppdm
Optionally connects remote PPDM system
-cross, --bi-directional
Optionally configures bi-directional communication between the two PPDM hosts
Use Cases
Let’s look at some common use cases for PPDM deployment:
1. Greenfield deployment of PPDM including registration of PowerProtect DD and vCenter:
# python ppdm_deploy.py -configfile ppdm_prod.json -vc -dd
2. PPDM deployment including registration of vCenter and DD as well as a remote PPDM system:
# python ppdm_deploy.py -configfile ppdm_prod.json -vc -dd -ppdm
3. Full deployment of two PPDM systems including configuration of the remote PPDM systems for bi-directional communication.
In this case, we would run the script twice in the following manner:
# python ppdm_deploy.py -configfile ppdm_siteA.json -vc -dd -ppdm -cross
# python ppdm_deploy.py -configfile ppdm_siteB.json -vc -dd
4. In case of evaluation or test purposes, the script can stop right after the PPDM OVA deployment:
# python ppdm_deploy.py -configfile ppdm_test.json -justova
5. In case of PPDM implementation where deployment needs to take place based on an existing PPDM VM or former OVA deployment:
# python ppdm_deploy.py -configfile ppdm_prod.json -skipova
Script output
# python ppdm_deploy.py -configfile ppdm_prod.json -vc -dd -ppdm -cross
-> Provisioning PPDM from OVA
Opening OVA source: C:\Users\idan\Downloads\dellemc-ppdm-sw-19.14.0-20.ova
Opening VI target: vi://idan%40vsphere.local@vcenter.hop.lab.dell.com:443/ProdDC/host/DC_HA1/
Deploying to VI: vi://idan%40vsphere.local@vcenter.hop.lab.dell.com:443/ProdDC/host/DC_HA1/
Transfer Completed
Powering on VM: PPDM_Prod_36
Task Completed
Completed successfully
---> OVA deployment completed successfully
-> Checking connectivity to PPDM
---> PPDM IP 10.0.0.36 is reachable
-> Checking PPDM API readiness
---> PPDM API is unreachable. Retrying
---> PPDM API is unreachable. Retrying
---> PPDM API is unreachable. Retrying
---> PPDM API is unreachable. Retrying
---> PPDM API is unreachable. Retrying
---> PPDM API is available
-> Obtaining PPDM configuration information
---> PPDM is deployment ready
-> Accepting PPDM EULA
---> PPDM EULA accepted
-> Applying license
-> Using Capacity license
-> Applying SMTP settings
-> Configuring encryption
-> Building PPDM deployment configuration
-> Time zone detected: Asia/Jerusalem
-> Name resolution completed successfully
-> Deploying PPDM
---> Deploying configuration 848a68bb-bd8e-4f91-8a63-f23cd079c905
---> Deployment status PROGRESS 2%
---> Deployment status PROGRESS 16%
---> Deployment status PROGRESS 20%
---> Deployment status PROGRESS 28%
---> Deployment status PROGRESS 28%
---> Deployment status PROGRESS 28%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 32%
---> Deployment status PROGRESS 36%
---> Deployment status PROGRESS 40%
---> Deployment status PROGRESS 40%
---> Deployment status PROGRESS 48%
---> Deployment status PROGRESS 48%
---> Deployment status PROGRESS 48%
---> Deployment status PROGRESS 48%
---> Deployment status PROGRESS 52%
---> Deployment status PROGRESS 52%
---> Deployment status PROGRESS 52%
---> Deployment status PROGRESS 52%
---> Deployment status PROGRESS 52%
---> Deployment status PROGRESS 56%
---> Deployment status PROGRESS 56%
---> Deployment status PROGRESS 56%
---> Deployment status PROGRESS 60%
---> Deployment status PROGRESS 60%
---> Deployment status PROGRESS 72%
---> Deployment status PROGRESS 76%
---> Deployment status PROGRESS 76%
---> Deployment status PROGRESS 80%
---> Deployment status PROGRESS 88%
---> Deployment status PROGRESS 88%
---> Deployment status PROGRESS 88%
---> Deployment status PROGRESS 88%
---> Deployment status PROGRESS 88%
---> Deployment status PROGRESS 88%
---> Deployment status SUCCESS 100%
-> PPDM deployed successfully
-> Initiating post-install tasks
-> Accepting TELEMETRY EULA
---> TELEMETRY EULA accepted
-> AutoSupport configured successfully
-> vCenter registered successfully
--> Hosting vCenter configured successfully
-> PowerProtect DD registered successfully
-> Connecting peer PPDM host
---> Monitoring activity ID 01941a19-ce75-4227-9057-03f60eb78b38
---> Activity status RUNNING 0%
---> Activity status COMPLETED 100%
---> Peer PPDM registered successfully
-> Configuring bi-directional replication direction
---> Monitoring activity ID 8464f126-4f28-4799-9e25-37fe752d54cf
---> Activity status RUNNING 0%
---> Activity status COMPLETED 100%
---> Peer PPDM registered successfully
-> All tasks have been completed
Where can I find it?
You can find the script and the config file in the official PowerProtect GitHub repository:
https://github.com/dell/powerprotect-data-manager
Resources
Other than the official PPDM repo on GitHub, developer.dell.com provides comprehensive online API documentation, including the PPDM REST API.
How can I get help?
For additional support, you are more than welcome to raise an issue in GitHub or reach out to me by email:
Thanks for reading!
Idan
Author: Idan Kentor
Related Blog Posts
PowerProtect Data Manager Automation – Lifecycle Management
Mon, 20 Nov 2023 15:42:26 -0000
|Read Time: 0 minutes
In this installment of the PowerProtect Data Manager (PPDM) automation series of blogs, we will focus on a new solution that automates PowerProtect Data Manager life cycle management.
For PPDM automation, we have auto-policy creation and ad-hoc VM backup solutions, use-case driven tasks, complete PPDM deployment automation, and so on - all available in the official PowerProtect Data Manager GitHub repository. And now, I am proud to present to you the PPDM life cycle automation solution.
So, let’s take a closer look at the solution.
What does the solution do?
The PowerProtect Data Manager automated life cycle management automates PPDM upgrades with a wide variety of options:
- Upgrade with an upload package
- Performs pre-upgrade checks
- Continuously monitors pre-upgrade checks and upgrade processes
- Includes an option to skip the upload of the upgrade package and use the existing upgrade package
- Can perform only the pre-checks, without performing the actual upgrade
- Supports monitoring only phase where a current upgrade can be monitored
- Allows to skip PPDM VM snapshot. In any case, that snapshot will not be taken if a hosting vCenter is not configured
What is the solution?
It is a Python-based script that operates with the PPDM REST API.
Here is the list of prerequisites:
- Python 3.x (The script supports every platform Python is supported on)
- Python requests module, which can be installed using pip with the command: “pip install requests” or “python -m pip install requests”
- PowerProtect Data Manager 19.13 and later
- Connectivity from the host running the script to PPDM, specifically on tcp ports 8443 and 14443
How do I use the script?
The script accepts the following parameters:
- The PPDM host is represented by the mandatory parameter server and username (defaults to user admin) and a mandatory password parameter
- The parameter file for a full path to the upgrade package or, alternatively the skipupload parameter with the release parameter to determine the PPDM version to be applied
- The parameter onlyprecheck allows to perform precheck and exit without performing the actual upgrade
- Specify skipsnapshot to prevent VM snapshot from being taken on the PPDM VM
- The onlymonitor parameter performs monitoring of active upgrades
Here is the full script syntax:
# python ppdm_upgrade.py -h usage: ppdm_upgrade.py [-h] -s SERVER [-u USERNAME] -p PASSWORD [-f UPGFILE] [-onlyprecheck] [-skipupload] [-release PPDMRELEASE] [-skipsnapshot] [-onlymonitor]
Script to automate PowerProtect Data Manager lifecycle management
options: -h, --help show this help message and exit -s SERVER, --server SERVER PPDM server FQDN or IP -u USERNAME, --username USERNAME Optionally provide the PPDM username -p PASSWORD, --password PASSWORD PPDM password -f UPGFILE, --file UPGFILE Full path to upgrade package -onlyprecheck, --only-pre-check Optionally stops after pre-check -skipupload, --skip-file-upload Optionally skips file upload -release PPDMRELEASE, --ppdm-release PPDMRELEASE Provide PPDM version if skipping package upload -skipsnapshot, --skip-snapshot Optionally skips PPDM VM snapshot -onlymonitor, --only-monitor Optionally only monitor running upgrade |
Use Cases and Examples
Let’s look at some common use cases for automated PPDM life cycle management:
1. PPDM automated upgrade, including file upload:
# python ppdm_upgrade.py -s 10.0.0.1 -p "myTempPwd!" -f /home/idan/dellemc-ppdm-upgrade-sw-19.14.0-27.pkg
2. For cases where there is a need to prepare for an upgrade by uploading the package and run the precheck. It is possible to perform the automated upgrade in two phases.
a. First, only file upload and precheck:
# python ppdm_upgrade.py -s 10.0.0.1 -p "myTempPwd!" -f /home/idan/dellemc-ppdm-upgrade-sw-19.14.0-27.pkg -onlyprecheck
b. Second, perform the upgrade itself:
# python ppdm_upgrade.py -s 10.0.0.1 -p "myTempPwd!" -skipupload -release 19.14.0-27
3. Monitoring a running upgrade from a different workstation:
# python ppdm_upgrade.py -s 10.0.0.1 -p "myTempPwd!" -onlymonitor
Script output
# python ppdm_upgrade.py -s 10.0.0.1 -p "myTempPwd!" -f /home/idan/dellemc-ppdm-upgrade-sw-19.14.0-27.pkg -> Obtaining PPDM configuration information ---> PPDM is upgrade ready -> Performing pre-upgrade version checks ---> Current PPDM version: 19.13.0-20 ---> Checking upgrade to PPDM version: 19.14.0-27 -> Uploading PPDM upgrade package ---> Upload completed successfully in 3 mins and 34 secs -> Monitoring upgrade ID 636cc6a3-2e84-4fb8-bb40-87aefd0f7b96 ---> Monitoring state AVAILABLE -> Performing pre-upgrade checks -> Monitoring upgrade ID 636cc6a3-2e84-4fb8-bb40-87aefd0f7b96 ---> Monitoring state PROCESSING ---> Monitoring state PROCESSING ---> Monitoring state PROCESSING ---> Monitoring state AVAILABLE -> Upgrading PPDM to release 19.14.0-27 ---> Monitoring PPDM upgrade ---> Upgrade status: PENDING ---> Upgrade status: RUNNING 3% ----> Upgrade info: current component: eCDM, description: Taking Update Snapshot 3% ----> Upgrade info: seconds elapsed / remaining: 11 / 2477 ---> Upgrade status: RUNNING 3% ----> Upgrade info: current component: eCDM, description: Taking Update Snapshot 3% ----> Upgrade info: seconds elapsed / remaining: 41 / 2447 ---> Upgrade status: RUNNING 3% ----> Upgrade info: current component: eCDM, description: Taking Update Snapshot 3% ----> Upgrade info: seconds elapsed / remaining: 53 / 2435 ---> Upgrade status: RUNNING 3% ----> Upgrade info: current component: eCDM, description: Taking Update Snapshot 3% ----> Upgrade info: seconds elapsed / remaining: 64 / 2424 ---> Upgrade status: RUNNING 10% ----> Upgrade info: current component: eCDM, description: Shutting Down Components 10% ----> Upgrade info: seconds elapsed / remaining: 211 / 2004 ---> Upgrade status: RUNNING 10% ----> Upgrade info: current component: eCDM, description: Shutting Down Components 10% ----> Upgrade info: seconds elapsed / remaining: 222 / 1993 ----> Upgrade info: seconds elapsed / remaining: 266 / 1949 ---> Upgrade status: RUNNING 21% ----> Upgrade info: current component: eCDM, description: Updating The RPMs 21% ----> Upgrade info: seconds elapsed / remaining: 277 / 1720 ---> Upgrade status: RUNNING 21% ----> Upgrade info: current component: eCDM, description: Updating The RPMs 21% ----> Upgrade info: seconds elapsed / remaining: 288 / 1709 ---> Upgrade status: RUNNING 21% ----> Upgrade info: current component: eCDM, description: Updating The RPMs 21% ----> Upgrade info: seconds elapsed / remaining: 299 / 1698 ---> Upgrade status: RUNNING 21% ----> Upgrade info: current component: eCDM, description: Updating The RPMs 21% ----> Upgrade info: seconds elapsed / remaining: 563 / 1486 ---> Polling timed out, retrying... ---> Polling timed out, retrying... ---> Polling timed out, retrying... ---> Upgrade status: RUNNING 32% ----> Upgrade info: current component: eCDM, description: Starting Components 32% ----> Upgrade info: seconds elapsed / remaining: 688 / 1167 ---> Upgrade status: RUNNING 35% ----> Upgrade info: current component: eCDM, description: Migrating Data 50% ----> Upgrade info: seconds elapsed / remaining: 776 / 1038 ---> Upgrade status: RUNNING 52% ----> Upgrade info: current component: eCDM, description: Data Migration Completed 52% ----> Upgrade info: seconds elapsed / remaining: 787 / 1038 ---> Upgrade status: RUNNING 55% ----> Upgrade info: current component: eCDM, description: Data Migration Completed 55% ----> Upgrade info: seconds elapsed / remaining: 940 / 1038 ---> Upgrade status: RUNNING 55% ----> Upgrade info: current component: eCDM, description: Data Migration Completed 55% ----> Upgrade info: seconds elapsed / remaining: 951 / 1038 ---> Upgrade status: RUNNING 57% ----> Upgrade info: current component: eCDM, description: Data Migration Completed 57% ----> Upgrade info: seconds elapsed / remaining: 962 / 1038 ---> Upgrade status: RUNNING 66% ----> Upgrade info: current component: eCDM, description: Data Manager Core Services Update Completed. Waiting for Other Components to Update... 71% ----> Upgrade info: seconds elapsed / remaining: 1027 / 1038 ---> Upgrade status: RUNNING 71% ----> Upgrade info: current component: eCDM, description: Data Manager Core Services Update Completed. Waiting for Other Components to Update... 71% ----> Upgrade info: seconds elapsed / remaining: 1038 / 1038 ---> Upgrade status: RUNNING 71% ----> Upgrade info: current component: eCDM, description: Data Manager Core Services Update Completed. Waiting for Other Components to Update... 71% ----> Upgrade info: seconds elapsed / remaining: 1049 / 1038 ---> Upgrade status: RUNNING 71% ----> Upgrade info: current component: eCDM, description: Data Manager Core Services Update Completed. Waiting for Other Components to Update... 71% ----> Upgrade info: seconds elapsed / remaining: 1060 / 1038 ---> Upgrade status: RUNNING 71% ----> Upgrade info: current component: eCDM, description: Data Manager Core Services Update Completed. Waiting for Other Components to Update... 71% ----> Upgrade info: seconds elapsed / remaining: 1071 / 1038 ---> Upgrade status: RUNNING 71% ----> Upgrade info: current component: eCDM, description: Data Manager Core Services Update Completed. Waiting for Other Components to Update... 71% ----> Upgrade info: seconds elapsed / remaining: 1083 / 1038 ---> Upgrade status: RUNNING 71% ----> Upgrade info: current component: eCDM, description: Data Manager Core Services Update Completed. Waiting for Other Components to Update... 71% ----> Upgrade info: seconds elapsed / remaining: 1095 / 1038 ---> Upgrade status: RUNNING 71% ----> Upgrade info: current component: eCDM, description: Data Manager Core Services Update Completed. Waiting for Other Components to Update... 71% ----> Upgrade info: seconds elapsed / remaining: 1108 / 1038 ---> Upgrade status: RUNNING 71% ----> Upgrade info: current component: eCDM, description: Data Manager Core Services Update Completed. Waiting for Other Components to Update... 71% ----> Upgrade info: seconds elapsed / remaining: 1120 / 1038 ---> Upgrade status: RUNNING 71% ----> Upgrade info: seconds elapsed / remaining: 1350 / 1038 ---> Upgrade status: RUNNING 76% ----> Upgrade info: current component: TSDM, description: Transparent Snapshot Data Mover Update Started 76% ----> Upgrade info: seconds elapsed / remaining: 1361 / 1034 ---> Upgrade status: RUNNING 94% ----> Upgrade info: current component: TSDM, description: Transparent Snapshot Data Mover Update Completed 94% ----> Upgrade info: seconds elapsed / remaining: 1372 / 138 ---> Upgrade status: COMPLETED 100% ----> Upgrade completed in 22 mins and 56 seconds -> PPDM upgraded successfully -> Making sure PPDM is up and running ---> PPDM is available ---> PPDM is operational on version 19.14.0-27 -> All tasks completed successfully |
Where can I find it?
You can find the script in the official PowerProtect GitHub repository:
https://github.com/dell/powerprotect-data-manager
Resources
Other than the official PPDM repo on GitHub, developer.dell.com provides comprehensive online API documentation, including full API reference, tutorials, and use cases for PPDM REST API.
How can I get help?
For additional support, you are more than welcome to raise an issue in GitHub or reach out to me by email:
Idan.kentor@dell.com
Thanks for reading!
Idan
Local Replication with the PowerMax REST API, Working with Clones
Wed, 31 May 2023 19:48:07 -0000
|Read Time: 0 minutes
PowerMax arrays have several local replication features for administrators to use, depending on their needs. Happily, the PowerMax REST API supports all of these. Dell Technologies also provides them in pre-written Python functions as part of PyU4V (a Python package for managing the PowerMax RESasasT API) and as Ansible modules that support symclone functions. In this blog I provide examples and some background info about clones.
If you are not familiar with REST, you’ll enjoy reading one or both of these articles:
- https://infohub.delltechnologies.com/p/getting-started-with-rest-api-1/
- https://infohub.delltechnologies.com/p/getting-started-with-the-powermax-rest-api-time-for-a-rest/
Full API documentation is available on the developer hub here. Clone operations are under the replication resource of the API, with all endpoints prefixed https://{{base_url}}/ /replication/symmetrix/{symmetrixId}/storagegroup/{storageGroupId}/clone/.
Managing clones with the PowerMaxREST API
With symclone, PowerMax administrators can create cloned images of their data on demand. If you want to study up on symclone and its history with PowerMax and Symmetrix predecessors, see the blog PowerMax Attack of the Clones.
Clone copies tend to be used in environments where the copy data might be made available to a system for an extended period and only refreshed once in a while. This is in stark contrast to snapshots which are taken frequently, typically have shorter retention times, are available for quick restoration of data, and available to present near real-time copies of data that is constantly changing to test and dev environments.
Starting with Unisphere for PowerMax 10.0, one can use the User Interface and API to interact with symclone functionality. This opened the door to new functionality, and automation, that was previously only available through command line options. Let’s explore this functionality and concentrate on the how, and a little of the why.
Creating a clone on PowerMax with REST API
Just like with snapshots and the majority of operations with PowerMax REST API, clones are controlled at a storage group level. Users create a clone of all volumes in a storage group. Storage group operations make it simpler to manage clones because all devices are at the same point in time (using PowerMax Enginuity Continuity Assist Technology (ECA)) when the clone is created.
To create a clone copy of a storage group, perform a POST operation against the source storage group. (The documentation for the Create Clone API call is here.) Here’s a sample POST call:
https://{unisphereip}}:{{port}}/restapi/100/replication/symmetrix/{symmetrixId}/storagegroup/{storageGroupId}/clone/storagegroup { "target_storage_group_name": "target_storagegroup_name", "establish_terminate": true, "consistent": true }
The API call and payload shown here create a consistent clone of a source storage group with the clone devices present in the specified target storage group.
The additional parameter establish_terminate set to true signifies to the API to remove the clone relationship as soon as it’s activated. This action is only available on PowerMax arrays running PowerMaxOS 10 or higher.
To perform the same operation in a Python script with PyU4V, the code is simple:
import PyU4V api = PyU4V.U4VConn(username='smc',password='smc', server_ip='unisphereip', verify=None, array_id='000297600841') api.clone.create_clone(storage_group_id="REST_TEST", target_storage_group_id="REST_TEST_TGT", establish_terminate=True)
If you want to maintain a relationship between the source and target storage group after activating your clone, you can omit the key or variable establish_terminate and you can create clones with different capabilities. Note that no copying of tracks is done on the array so it can be easier to use this function because code will be shorter (because there are no relationships to track), and the data is available to the host as soon as the clone is created. So there’s no need to wait for any background operations.
Clone and SnapVX better together
Providing developers with copies of data for building applications, to provide business advantages and to deliver user features to customers, is part and parcel of many organizations. However, the security of that data is paramount and often has legal requirements depending on location and industry.
A great way to help in situations like this is to use clone and snap technology together to create a standalone copy of the data that can be mounted to a host for obfuscation. This helps make sure that sensitive information like social security numbers are no longer intelligible. One can then take snapshots from the obfuscated clone and link them to any test or dev servers.
After the sensitive data has been scrambled by the obfuscation process and RBAC applied to the clones, developers with Local Replication rights can refresh their snapshots at will without security concerns about the data they are seeing. They will only be able to run API calls against storage groups for which they have been granted privileges.
Restoring Data from a Clone
From time-to-time you may want to restore data from a clone to the source. If you are using the traditional clone workflow and have not used the establish/terminate options, you can use the modify storage group clone PUT API call, using the API call here with the restore action.
The URI and body are here:
https://{unisphereIP}:8443/univmax/restapi/100/replication/symmetrix/{symmetrixId}/storagegroup/{storageGroupId}/clone/storagegroup/{targetStorageGroupId} { "action": "Restore", "restore": { "force": "false", "star": "false" } }
PyU4V has its own function for the restore action, taking the source and target storage groups names as parameters:
api.clone.restore_clone( storage_group_id="mysrc_sg", target_storage_group_id="mytgt_sg" ) conn.clone.terminate_clone( storage_group_id="mysrc_sg", target_storage_group_id="mytgt_sg", restored=True)
After the restore, you must terminate the restored session on the source storage group before any additional clone commands can run.
As with any feature, it’s easy to do things when you know how, but as with any technology there are rules which are well documented here. In that document, Table 5 lists the states and allowed actions. (Though this is a command line document, the rules are the same for API and UI operations.)
Hopefully this short blog has given some insight and possibly some inspiration into how to use PowerMax clone technologies with the REST API interfaces.
Watch this space for more about the PowerMax API, and if there are topics that are of interest to you and you would like to read more, send a request to @rawstorage on Twitter and I’ll try to accommodate your request!
Author: Paul Martin