A Shell enables CloudShell users to interact with different sandbox elements, like physical devices and virtual appliances. A Shell models the sandbox element in CloudShell and provides commands that CloudShell users and automation processes can run on it, like Power On and Health Check.
CloudShell Shells are either 1st Generation Shells or 2nd Generation Shells. Both types of Shells can coexist with each other in the same CloudShell sandbox but differ in their structure and how they are managed.
Note: The Shell’s type is indicated with a “1st Gen” or “2nd Gen” label in the CloudShell Developer Center.
- 1st Generation Shells are imported as CloudShell packages that contain the data model and driver for the intended sandbox element. 1st Generation Shells allow extensive control of the family and model, and therefore are not standardized. While they allow maximal flexibility, when using them, some Shell management capabilities may not be available.
- 2nd Generation Shells are imported through CloudShell Portal's Shells management page. 2nd Generation Shells are based on standardized models and attributes, which streamlines the creation, maintenance and sharing of Shells.
Note: Depending on your organization, the system administrator and domain administrator may be the same employee.
- The system administrator imports the Shell into CloudShell, as explained in Importing Shells.
In the Inventory dashboard, the domain administrator creates a resource based on the Shell. For additional information, see Adding Inventory Resources.
The resource is available for the domain’s users.
- Blueprint designers add the resource to the blueprint, and if needed, configure connectivity to other elements in the blueprint.