Save a Sandbox
Saving a sandbox is part of the Save and Restore paid add-on. Contact your account manager to purchase a license. For details about Save and Restore, see Sandbox Save and Restore Overview.
This article explains how to save a sandbox.
Note: CloudShell also has a Save As Blueprint option. However, unlike Save As Sandbox, it only saves the diagram and properties of the sandbox but not the state of the sandbox and the sandbox's components. For additional information, see Save a Sandbox as a Blueprint.
In this article:
Saving a sandbox
To save a sandbox:
In the sandbox workspace, click the Save Sandbox button.
Note:You can only save a sandbox when the sandbox is in the "Active" or "Active (with Error)" state.
The Save Sandbox dialog box is displayed.
Enter a meaningful Name.
The default is the sandbox name with a "- Save" added to the end of the name. For example: “Traffic Test with additional configurations – Save”.
Note: The saved sandbox name has a limit of 60 characters.
Optionally, enter a Description. It is recommended that you include a description. For example, to help you differentiate between saved sandboxes that are based on the same sandbox.
By default, the saved sandbox description is empty.
Click Save.
CloudShell creates a saved sandbox. When the saving process completes, the saved sandbox is displayed in the Saved Sandboxes dashboard and the original sandbox is available for use. Note that only the user that created the saved sandbox (and admins) can see the saved sandbox and restore it. They can restore it and then invite permitted users to the new restored sandbox. For details about what information is saved, see the section below.
Sandbox saving state
When you click Save in the Save Sandbox dialog box, a save script is called and the sandbox enters the Saving state.
Note: While the sandbox is in the saving state, the sandbox is in "view only" mode and cannot be used.
If the sandbox teardown starts before the saving process completes, the saving process will be canceled. To avoid such a scenario, ensure that the sandbox duration is set so that you have enough time to save the sandbox. If you do not, extend the sandbox duration. See Extend and End Sandboxes for more information.
Once the saving action completes successfully, a saved sandbox is created and the sandbox returns to the active state. You can then continue working in the sandbox and save additional instances, if required.
Sandbox save logic
Currently, CloudShell supports saving sandboxes that contain vCenter-based Apps, inventory resources and CloudShell services. Apps of other cloud providers are not supported and therefore, you cannot save a sandbox which contains these elements.
When you save a sandbox, the save logic runs in CloudShell and triggers the vCenter's save command on the vCenter servers, which have deployed Apps in the sandbox.
In the following tables, you will find a detailed explanation of the sandbox components CloudShell saves during the saving process:
Sandbox elements
| Cloud Providers | Only vCenter Apps can be saved. Saving sandboxes with Apps based on other cloud providers is currently not supported. |
| Inventory Resources | Starting with CloudShell 9.1, inventory resources can be saved. Notes:
|
| Static vCenter VMs | CloudShell 9.1 GA supports saving sandboxes that contain static vCenter VMs (i.e. vCenter VMs which are modeled in CloudShell's Inventory dashboard, but are not deployed via CloudShell). CloudShell views such components as inventory resources and therefore does not clone these VMs or save their state, as it does for deployed vCenter Apps. |
Services | When saving a sandbox that contains services, the services are copied along with their attribute values. If the services have published inputs, the values that were entered when the original sandbox was reserved are also saved. |
| Attachments | Sandbox attachments are not saved. |
| Labels | The sandbox's labels are saved, including unused labels that were created in the originating blueprint. |
vCenter Apps
| Deployed Apps | Each deployed App in the original sandbox represents a running vCenter VM, which was deployed by the App in the sandbox. When saving, CloudShell clones this VM, and creates a snapshot of the cloned VM on the vCenter server. Optionally, you can configure CloudShell to power off the original VM for the duration of the saving process using the Behavior During Saveattribute, as explained in vCenter advanced saving configurations. In the vCenter server, cloned VMs reside in a folder named as the saved sandbox ID. This folder is located within the Saved Sandboxes folder, defined in the VM Location attribute on the vCenter cloud provider resource. For example:
The VM Location folder is located in the vCenter data storage defined on the vCenter cloud provider resource, unless a different value was defined in the Saved Sandbox Storage field on the App template, as explained in vCenter advanced saving configurations. Important notes:
|
| Non-Deployed Apps | If the sandbox you want to save includes vCenter Apps that were not yet deployed, these Apps will be copied as is to the saved sandbox without creating any artifacts in vCenter. Note: When restoring a saved sandbox, the Restore script will deploy these Apps, even though they were not already deployed when the original sandbox was saved. |
Connectivity
Starting with CloudShell 9.1, the sandbox saving process also copies L1 connections (including visual, physical cable requests) between sandbox components, including the connection's direction, alias and attributes (if specified).
| L1 Connectivity | The route's endpoint information is copied, not the route solution. The save procedure also supports scenarios where connections are created after the sandbox was created and therefore do not exist in the blueprint. |
| Mappable resources | Mappable resources such as L1s and Patch Panels are not copied. |
| Physical cable requests | Physical cable requests on a resource are copied as is and not disconnected. |
| Visual connections | Visual connections between endpoints in the sandbox are copied. |
| L2 Connectivity | L2 connections and VLAN services are copied to the saved sandbox.
For more information about VLAN services, see VLAN Connectivity. |
| L3 Connectivity | L3 connections are not copied. |
Additional information
- The original sandbox's properties, including the blueprint's properties such as orchestration settings, instructions, and configurations are also saved in the restored sandbox, and some reservation properties, including permitted users, and email notifications.
- Sandbox inputs, such as global inputs and published service inputs, are saved with the values that were entered when the sandbox was reserved. These input values are set in the restored sandbox and cannot be changed when restoring.
