Configure a Cisco UCSD Cloud


The CloudCenter platform provides Cisco Unified Computing Systems Director (UCSD) integration that enables you to invoke UCSD callout workflows. Users can drag and drop the Cisco UCSD service into the CloudCenter Topology Modeler and create a topology with single or multiple UCSD callouts. This allows enterprises to create a mixed topology of applications using UCSD callouts and provides the following benefits:

  • Enterprises can use CloudCenter for governance as well as workflow management.  

  • SysAdmins can use UCSD to provision physical storage.


Be aware of the following limitations if you decide to use this integration:

  • The CloudCenter platform does not support HA environments for UCSD workflows.

  • See Phase 1: Prepare Infrastructure for release compatibility details.

  • This implementation of the UCSD integration allows you to provision your storage setup on network appliances (tested and verified for the CloudCenter platform).

    UCSD currently allows VM provisioning.

  • This feature has been tested and implemented for select customers.

  • This CloudCenter release only supports the version that is explicitly listed in Datacenters and Private Clouds.

  • Worker1 appliances are not required for this integration.

  • CCM and CCO appliances are not available for this integration.

  • When you create an External Initialization Script (see External Service) for a cloud region and launch a UCSD workflow from the CCM, the workflow is executed but the region-level External Initialization Script is not executed. This is because the External Initialization Script (PreVM init) is generally executed before a VM is launched and there is no VM being launched in UCSD.

  • Even if you have multiple UCSD accounts in CloudCenter when modeling an application, the CloudCenter platform does not allow you to select a specific region of UCSD. Essentially, you can only have one UCSD account for each CloudCenter platform.

Integration Requirements

To integrate with Cisco UCSD, the CloudCenter SysAdmin must adhere to the following requirements:

  • Administrator ability to access to the Cisco UCSD account and environment.

    If you intend to integrate UCSD in your enterprise, the CloudCenter platform requires access to the UCSD environment to provide end-to-end deployment.

  • Knowledge of the list of UCSD workflows to be called by the CloudCenter platform.

    The CloudCenter platform abstracts the orchestration process to use the callout flows exposed by UCSD. The CloudCenter platform merely uses exposed UCSD parameters for cloud governance and management purposes.

  • Each Cisco UCSD instance must be associated with a CCO before you Model an Application.

  • Currently, one CloudCenter platform supports one UCSD instance.

  • Each CloudCenter UCSD implementation requires an associated physical image entry in the CloudCenter platform (this is a dummy placeholder – even if a logical Image is not used).

  • As the CloudCenter platform does not rely on the Cloudblade (cloudblade) service for UCSD integrations, you can safely shutdown this service as specified in Component-Specific Processes > Stopping a Process.

    Shutting down this service is a temporary solution as the service will be restarted when the server is rebooted.

    To permanently disable the cloudblade service, see Component-Specific Processes > Disabling a Process.

  • If using a VMware Appliance Setup, you can enable the UCSD cloud provider in the CCO server by following this procedure.

    1. SSH to the CCO and navigate to the directory /usr/local/osmosix/etc in each CCO .

    2. Ensure that CiscoUCSD is displayed in its contents.

      [root@ucsd65-cco-49 Jul9-4.9.1]# cat /usr/local/osmosix/etc/cloud
    3. Ensure that the cloud value is set to CiscoUCSD in its contents.

      [root@ucsd65-cco-49 Jul9-4.9.1]# cat /usr/local/osmosix/etc/
    4. Restart the Gateway service so the CCO server automatically uses Cisco UCSD in its configuration.

      systemctl restart gateway

UCSD Workflow Support

UCSD has the concept of workflows. These workflows differ between enterprises and deployments. An example of such a workflow is when you provision storage using the UCSD integration, CloudCenter currently calls the following workflows:

  • Create a new storage space or VM (generally referred to as resource)

  • Validate the existence of a storage space

  • Update an existing storage space

  • Delete a storage space

  • Retrieve information about a storage space

UCSD Workflow Requirements from CloudCenter Perspective

The CloudCenter platform requires the following UCSD IDs:

  • Service Request ID: This ID is generated by the UCSD workflow. The CloudCenter platform uses this ID.

  • Resource ID: In the Deployment workflow when you create a new storage space or VM, the CloudCenter platform expects to receive the resource ID (the ID of the provisioned resource) of the UCSD workflow as an output parameter.

The CloudCenter termination workflow (that a UCSD user sets up) should typically use this Resource ID to refer to the originally provisioned entity and remove that entity as required.

For example:

  • If your workflow needs to provision a storage system, your workflow should return a Storage ID as the Resource ID.

  • If your workflow needs to launch a VM, it could return the VM ID as the Resource ID.

The following is a basic sample script to return a Resource ID from a UCSD workflow task.

//// return value for Cisco CloudCenter
var srid=ctxt.getSrId();
logger.addInfo("SR ID: " + srid);
json_output="{"resourceId":"" + srid + ""}";
logger.addInfo("json_output: " + json_output);


Configure UCSD as a Custom Service

The current UCSD workflows are specific to the creation and maintenance of additional storage work spaces for enterprises. As UCSD is associated with one CCO, each time you access information about the storage space, the CCO retrieves the permitted UCSD workflows.

To configure, define, and use UCSD as a custom service, follow this process:

  1. Access the CCM UI > Admin > Clouds > Add Cloud in the CCM UI main menu.

  2. Select the Cisco UCSD option, provide a Name and Description for this cloud, and click Save.

  3. Edit or create the instance type using the following details. See Manage Instance Types for additional context.

  4. Edit or create the cloud mapping using the following details. See Map Images for additional context.

  5. To complete the cloud configuration, you must register the CCO with the CCM.

     Register the CCO with the CCM

    Register the CCO with the CCM

    Cloud Region Nuances

    Once you register a CCO with the CCM, the CCO only works for the registered cloud region.


    Once you register a CCO with the CCM, the CloudCenter platform considers this cloud region to be active and you can only delete the cloud region from the CloudCenter platform under specific conditions. See Cloud Region Configuration > Delete Cloud Region for additional details.

    While the example provided references the AWS cloud, be aware that the screen captures may differ for each cloud.

    Registration Process

    To register the CCO with the CCM, follow this procedure:

    1. In the Configure Orchestrator popup, provide the CCO IP address that is accessible by CCM and select the cloud account that is used to host the CCO:

    2. If you are not already at this page, verify that you are in the Configure Regions page (Admin > Clouds > Configure Regions for the required cloud).

      1. Click Configure Orchestrator in the Regions tab.

      2. Orchestrator IP or DNS: Provide the IP or DNS address for the CCO server.

      3. Remote Desktop Gateway DNS or IP: The IP address of the Guacamole server (enables browser-based access to the VMs). If the Guacamole component resides in the AMQP server, provide the IP address of the AMQP server.

      4. Cloud Account: Select the cloud account that you want to use with this CCO.

        Amazon Cloud Nuance

        This setting is important if you have configured an IAM Role. Be sure to select the cloud account that contains this role.

    3. Click Save. The CCM and CCO have now established a mutual trust relationship. The CloudCenter platform now manages the cloud region with the deployed CCO.

      If in HA mode while registering, provide the IP or DNS of the CCO_LB server in the Orchestrator IP or DNS field and the AMQP_LB server IP or DNS in the Remote Desktop Gateway DNS or IP field.

    You have registered the CCO VM and completed your configuration.

    Next Steps

    You have the following options at this point:

  6. Add UCSD as the deployment environment. See Deployment Environments.

  7. Edit the Cisco UCSD service to define the allowed UCSD workflow parameters. See Custom Service Definition.

  8. Model a new N-tier application to use the Cisco UCSD service. See Model an Application for additional context.

  9. Save and deploy the UCSD application.


You have now configured and launched UCSD as a custom service.

Sample UCSD Workflows

These workflow are merely samples – Be aware that the workflow will differ based on your local environment!

This is a sample of a custom task that returns the instance ID.

This is a sample of the global output:

This is the sample of a custom task mapping within the workflow for the Service Request ID to be returned to the CloudCenter platform:

This is the sample of a Resource ID being returned to the CloudCenter platform – When talking to UCSD, the CloudCenter platform requires the last task to report a Resource ID back to the CloudCenter platform. This resource ID can be the UCSD Service Request ID. A custom task must provide this function.

This is a sample termination workflow:

The same sample workflow from the CloudCenter perspective:

Cisco CloudCenter expects the termination workflow to have that input label (the Resource ID) as it injects the ID that was returned from the original JSON output.

This is a sample workflow input:

This is a sample termination and rollback in UCSD:

Return to: Configure Cloud(s)

  • No labels
Terms & Conditions Privacy Statement Cookies Trademarks