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.
- Save and Restore does not apply to persistent environments.
- 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:
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.
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 admins and permitted users of the saved sandbox can see 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.
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.
Currently, CloudShell supports saving sandboxes that contain vCenter/OpenStack-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/OpenStack's save command on the vCenter/OpenStack 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:
|Apps||Only vCenter/OpenStack Apps can be saved. Saving sandboxes with Apps based on other cloud providers is currently not supported. Save and Restore applies to all vCenter 2G shell versions and OpenStack 2G shell version 1.2.0 and above.|
Inventory resources can be saved.
|Static VMs||CloudShell supports saving sandboxes that contain static VMs (i.e. 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 Apps.|
|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.|
Each deployed App in the original sandbox represents a running 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/OpenStack server. Optionally, you can configure CloudShell to power off the original VM for the duration of the saving process using the Behavior During Save attribute, as explained in vCenter/OpenStack advanced saving configurations.
If the sandbox you want to save includes vCenter/OpenStack Apps that were not yet deployed, these Apps will be copied as is to the saved sandbox without creating any artifacts in vCenter/OpenStack.
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.
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).
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 connections and VLAN services are copied to the saved sandbox.
For more information about VLAN services, see VLAN Connectivity.
L3 connections are not copied.
- 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.