Install the Crosswork Cluster

This chapter contains the following topics:

Installation Parameters

This section explains the important parameters that must be specified while installing the Crosswork cluster. Kindly ensure that you have relevant information to provide for each of the parameters mentioned in the table and that your environment meets all the requirements specified under Cisco Crosswork Installation Requirements.


Note

Some of the below parameters may be named differently depending upon the destination platform (vCenter or Amazon EC2), the installation method (automated or manual), and IP stack (IPv4 or IPv6) you choose.


Note

Secure ZTP and Secure Syslog require the Crosswork cluster to be deployed with FQDN.
Table 1. General parameters

Parameter Name

Description
ClusterName

Name of the cluster file
ClusterIPStack

The IP stack protocol: IPv4 or IPv6
ManagementIPAddress

The Management IP address of the VM (IPv4 or IPv6).

ManagementIPNetmask

The Management IP subnet in dotted decimal format (IPv4 or IPv6).
ManagementIPGateway

The Gateway IP on the Management Network (IPv4 or IPv6). The address must be reachable, otherwise the installation will fail.
ManagementVIP

The Management Virtual IP for the cluster.
ManagementVIPName

Name of the Management Virtual IP for the cluster. This is an optional parameters used to reach Crosswork cluster Management VIP via DNS name. If this parameter is used, the corresponding DNS record must exist in the DNS server and must match the ManagementVIP and ManagementVIPName.

DataIPAddress

The Data IP address of the VM (IPv4 or IPv6).
DataIPNetmask

The Data IP subnet in dotted decimal format (IPv4 or IPv6).
DataIPGateway

The Gateway IP on the Data Network (IPv4 or IPv6). The address must be reachable, otherwise the installation will fail.
DataVIP

The Data Virtual IP for the cluster.
DataVIPName

Name of the Data Virtual IP for the cluster. This is an optional parameters used to reach Crosswork cluster Data VIP via DNS name. If this parameter is used, the corresponding DNS record must exist in the DNS server and must match the DataVIP and DataVIPName.

DNS

The IP address of the DNS server (IPv4 or IPv6). The address must be reachable, otherwise the installation will fail.
NTP

NTP server address or name. The address must be reachable, otherwise the installation will fail.
DomainName

The domain name used for the cluster.
CWusername

Username to log into Cisco Crosswork.

This is an optional parameter.

CWPassword

Password to log into Cisco Crosswork.

Use a strong VM Password (8 characters long, including upper & lower case letters, numbers, and one special character). Avoid using passwords similar to dictionary words (for example, "Pa55w0rd!") or relatable words (for example, C!sco123 or Cwork321!). While they satisfy the criteria, such passwords are weak and will result in the failure of VM setup. You are recommended to use a password with more characters and complex combinations.

VMSize

VM size for the cluster. Value is large.

VMName

Name of the VM

You will require at least 3 unique names (one for each VM).

VMType

Indicates the type of VM. Choose either "Hybrid" or "Worker".

Note

 

The Crosswork cluster for 4.5 release requires at least three VMs operating in a hybrid configuration.
IsSeed

Choose "True" if this is the first VM being built in a new cluster.

Choose "False" for all other VMs, or when rebuilding a failed VM.

This paramater is optional for installing using the cluster installer tool.

InitNodeCount

Total number of nodes in the cluster including Hybrid and Worker nodes. The default value is 3.

This paramater is optional for installing using the cluster installer tool.

InitMasterCount

Total number of Hybrid nodes in the cluster. The default value is 3.

This paramater is optional for installing using the cluster installer tool.

BackupMinPercent

Minimum percentage of the data disk space to be used for the size of the backup partition. The default value is 50 (valid range is from 1 to 80).

Please use the default value unless recommended otherwise.

Note

 

The final backup partition size will be calculated dynamically. This parameter defines the minimum.
ManagerDataFsSize

Refers to the data disk size for Hybrid nodes (in Giga Bytes). This is an optional parameter and the default value is 450 (valid range is from 450 to 8000), if not explicitly specified.

Please use the default value unless recommended otherwise.
WorkerDataFsSize

Refers to the data disk size for Worker nodes (in Gigabytes). This is an optional parameter and the default value is 450 (valid range is from 450 to 8000), if not explicitly specified.

Please use the default value unless recommended otherwise.
ThinProvisioned

Thin or thick provisioning for all disks. Set as "false" for live production deployments, and "true" for lab deployments.

EnableHardReservations

Determines the enforcement of VM CPU and Memory profile reservations (see VMware Resource Requirements for more information). This is an optional parameter and the default value is true, if not explicitly specified.

If set as true, the VM's resources are provided exclusively. In this state, the installation will fail if there are insufficient CPU cores, memory or CPU cycles.

If set as false (only set for lab installations), the VM's resources are provided on best efforts. In this state, the installation will fail if there are insufficient CPU cores.

RamDiskSize

Size of the Ram disk.

This parameter is only used for lab installations (value must be at least 2). When a non-zero value is provided for RamDiskSize, the HSDatastore value is not used.

OP_Status

The state for this VM. To indicate a running status, the value must be 2 (#OP_Status = 2).

This is an optional parameter.

This parameter is used (uncommented) only for manually importing the inventory without using the installer.

SchemaVersion

The configuration Manifest schema version
LogFsSize

Log partition size (in Giga Bytes). Minimum value is 10 GB and Maximum value is 1000 GB.

Table 2. VMware template parameters

Parameter Name

Description
vCenterAddress

The vCenter IP or host name.
vCenterUser

The username needed to log into vCenter.
vCenterPassword

The password needed to log into vCenter.
DCname

The name of the Data Center resource to use.
MgmtNetworkName

The name of the vCenter network to attach to the VM's Management interface.
DataNetworkName

The name of the vCenter network to attach to the VM's Data interface.
Host

The ESXi host or resource group name.
Datastore

The datastore name available to be used by this host or resource group.
HSDatastore

The high speed datastore available for this host or resource group.
DCfolder

The resource folder name on vCenter. Leave as empty if not used.
Cw_VM_Image

The name of Crosswork cluster VM image in vCenter. If left blank, the name is generated from the uploaded image.
HostedCwVMs

The IDs of the VMs to be hosted by the ESXi host or resource. These have to match to the Crosswork cluster VM.
Table 3. Amazon EC2 template parameters

Parameter Name

Description
ManagementPeerIPs

The Management IP addresses of all the deployed VMs.
DataPeerIPs

The Data IP addresses of all the deployed VMs.
AwsIamRole

The Identity and Access Management (IAM) user id created for by your AWS account administrator to build the cluster virtual machines.

K8sServiceNetwork

The network address for the kubernetes service network. The CIDR range is fixed to '/16'.

This is an optional parameter.
K8sPodNetwork

The network address for the kubernetes pod network. The CIDR range is fixed to '/16'.

This is an optional parameter.

Install Cisco Crosswork on VMware vCenter

This section describes how Cisco Crosswork is installed on VMware vCenter:

Install Cisco Crosswork on VMware vCenter using Cluster Installer tool

This section explains the procedure to install Cisco Crosswork on VMware vCenter using the cluster installer tool.


Attention

The file names mentioned in this topic are sample names and may differ from the actual file names in cisco.com.

Before you begin

Few pointers to know when using the cluster installer tool:

  • Make sure that your environment meets all the vCenter requirements specified under Crosswork Cluster VM Requirements and Installation Requirements in VMware vCenter.

  • The install script is safe to run multiple times. Upon error, input parameters can be corrected and re-run. However, it must be noted that running the tool multiple times may result in the deletion and re-creation of VMs.

  • The edited template in the /data directory will contain sensitive information (VM passwords and the vCenter password). The operator needs to manage access to this content. Store them in a secure environment or edit them to remove the passwords.

  • The install.log, install_tf.log, and crosswork-cluster.tfstate files will be created during the install and stored in the /data directory. If you encounter any trouble with the installation, provide these files to the Cisco Customer Experience team when opening a case.

  • In case you are using the same installer tool for multiple Crosswork cluster installations, it is important to run the tool from different local directories, allowing for the deployment state files to be independent. The simplest way for doing so is to create a local directory for each deployment on the host machine and map each one to the container accordingly.

  • Docker version 19 or higher is required while using the cluster installer option. For more information on Docker, see https://docs.docker.com/get-docker/

  • In order to change install parameters or to correct parameters following installation errors, it is important to distinguish whether the installation has managed to deploy the VMs or not. Deployed VMs are evidenced by the output of the installer similar to:

    vsphere_virtual_machine.crosswork-IPv4-vm["1"]: Creation complete after 2m50s [id=4214a520-c53f-f29c-80b3-25916e6c297f]

    In case of deployed VMs, changes to the Crosswork VM settings or the Data Center host for a deployed VM are NOT supported. To change a setting using the installer when the deployed VMs are present, the clean operation needs to be run and the cluster redeployed. For more information, see Delete the VM using the Cluster Installer.

  • A VM redeployment will delete the VM's data, hence caution is advised. We recommend you perform VM parameter changes from the Crosswork UI, or alternatively one VM at a time. Installation parameter changes that occur prior to any VM deployment, e.g. an incorrect vCenter parameter, can be performed by applying the change and simply re-running the install operation.


Note

The installer tool will deploy the software and power on the virtual machines. If you wish to power on the virtual machines yourself, use the manual installation.

Procedure

Step 1

In your vCenter datacenter, go to Host > Configure > Networking > Virtual Switches and select the virtual switch. In the virtual switch, select Edit > Security, and configure the following DVS port group properties:

  • Set Promiscuous mode as Reject

  • Set MAC address changes as Reject

Confirm the settings and repeat the process for each virtual switch used in the cluster.

Step 2

In your Docker capable machine, create a directory where you will store everything you will use during this installation.

Note

 

If you are using a Mac, please ensure that the directory name is in lower case.

Step 3

Download the installer bundle (.tar.gz file) and the OVA file from cisco.com to the directory you created previously. For the purpose of these instructions, we will use the file names as "cw-na-platform-4.4.0-signed-installer.tar.gz" and "cw-na-platform-4.4.0-250-release-221027.ova" respectively.

Step 4

Use the following command to unzip the installer bundle:

tar -xvf cw-na-platform-4.4.0-signed-installer.tar.gz

The contents of the installer bundle is unzipped to a new directory (e.g. cw-na-platform-4.4.0-signed-installer). This new directory will contain the installer image (e.g. cw-na-platform-installer-4.4.0-250-release-221027.tar.gz) and files necessary to validate the image.

Step 5

Review the contents of the README file in order to understand everything that is in the package and how it will be validated in the following steps.

Step 6

Navigate to the directory created in the previous step and use the following command to verify the signature of the installer image:

Note

 

Use python --version to find out the version of python on your machine.

If you are using python 2.x, use the following command to validate the file:

python cisco_x509_verify_release.py -e <.cer file> -i <.tar.gz file> -s <.tar.gz.signature file>
-v dgst -sha512

If you are using python 3.x, use the following command to validate the file:

python cisco_x509_verify_release.py3 -e <.cer file> -i <.tar.gz file> -s <.tar.gz.signature file>
-v dgst -sha512

Note

 

If you do not get a successful verification message, please contact the Cisco Customer Experience team.

Step 7

Use the following command to load the installer image file into your Docker environment.

docker load -i <.tar.gz file>

For example: 

docker load -i cw-na-platform-installer-4.4.0-250-release-221027.tar.gz

Step 8

Run Docker image list or Docker images command to get the "image ID" (which is needed in the next step).

For example: 

docker images

The result will be similar to the following: (section we will need is underlined for clarity)

My Machine% docker images
REPOSITORY                        TAG                                                 IMAGE ID             CREATED        SIZE
dockerhub.cisco.com/cw-installer  cw-na-platform-installer-4.4.0-250-release-221027   a4570324fad30  7 days ago     276MB

Note

 

Pay attention to the "CREATED" time stamp in the table presented when you run docker images, as you might have other images present from the installation of prior releases. If you wish to remove these, the docker rm {image id} command can be used.

Step 9

Launch the Docker container using the following command:

docker run --rm -it -v `pwd`:/data {image id of the installer container}

To run the image loaded in our example, the command would be: 

docker run --rm -it -v `pwd`:/data a4570324fad30

Note

 

  • You do not have to enter that full value. In this case, "docker run --rm -it -v `pwd`:/data a45" was adequate. Docker requires enough of the image ID to uniquely identify the image you want to use for the installation.

  • In the above command, we are using the backtick (`). Do not use the single quote or apostrophe (') as the meaning to the shell is very different. By using the backtick (recommended), the template file and OVA will be stored in the directory where you are on your local disk when you run the commands, instead of inside the container.

  • When deploying a IPv6 cluster, the installer needs to run on an IPv6 enabled container/VM. This requires additionally configuring the Docker daemon before running the installer, using the following method:

    • Linux hosts (ONLY): Run the Docker container in host networking mode by adding the "–network host" flag to the Docker run command line. 

      docker run --network host <remainder of docker run options>

  • Centos/RHEL hosts, by default, enforce a strict SELinux policy which does not allow the installer container to read from or write to the mounted data volume. On such hosts, run the Docker volume command with the Z option as shown below: 

    docker run --rm -it -v `pwd`:/data:Z <remainder of docker options>

Note

 

The Docker command provided will use the current directory to read the template and the ova files, and to write the log files used during the install. If you encounter either of the following errors you should move the files to a directory where the path is in lowercase (all lowercase, no spaces or other special characters).

Error 1: 

% docker run --rm -it -v `pwd`:/data a45
docker: invalid reference format: repository name must be lowercase.
See 'docker run --help'

Error 2:

docker: Error response from daemon: Mounts denied: approving /Users/Desktop: file does not exist
ERRO[0000] error waiting for container: context canceled

Step 10

Navigate to the directory with the VMware template.

cd /opt/installer/deployments/4.4.0/vcenter

Step 11

Copy the template file found under /opt/installer/deployments/4.4.0/vcenter/deployment_template_tfvars to the /data folder using a different name.

For example: cp deployment_template_tfvars /data/deployment.tfvars

For the rest of this procedure, we will use deployment.tfvars in all the examples.

Step 12

Edit the template file located in the /data directory in a text editor, to match your planned deployment. Refer to the Installation Parameters table for details on the required and optional fields and their proper settings. The Sample manifest template for VMware vCenter includes an example that you can reference for proper formatting. The example is more compact due to the removal of descriptive comments:

  • Crosswork cluster information such as VM size: Use "Large" for production environments. For more information, see the storage profiles in Crosswork Cluster VM Requirements.
  • Unique Crosswork VM entries, including names, their IP addresses and node type settings.

    Note

     
    Use a strong VM Password (8 characters long, including upper & lower case letters, numbers, and one special character). Avoid using passwords similar to dictionary words (for example, "Pa55w0rd!") or relatable words (for example, C!sco123 or Cwork321!). While they satisfy the criteria, such passwords are weak and will result in the failure of VM setup.
  • vCenter access details and credentials, along with the assignment of the named Crosswork VMs to the Data Center resources.

Step 13

Run the installer. 

./cw-installer.sh install -p -m /data/<template file name> -o /data/<.ova file>

For example:

./cw-installer.sh install -p -m /data/deployment.tfvars -o /data/cw-na-platform-4.4.0-250-release-221027.ova

Step 14

Read, and then enter "yes" when prompted to accept the End User License Agreement (EULA).

Step 15

Enter "yes" when prompted to confirm the operation.

Note

 

It is not uncommon to see some warnings like the following during the install: 

Warning: Line 119: No space left for device '8' on parent controller '3'.
Warning: Line 114: Unable to parse 'enableMPTSupport' for attribute 'key' on element 'Config'.

If the install process proceeds to a successful conclusion (see sample output below), these warnings can be ignored.

Sample output:

cw_cluster_vms = <sensitive>
INFO: Copying day 0 state inventory to CW
INFO: Waiting for deployment status server to startup on 10.90.147.66. Elapsed time 0s, retrying in 30s
Crosswork deployment status available at http://{VIP}:30602/d/NK1bwVxGk/crosswork-deployment-readiness?orgId=1&refresh=10s&theme=dark 
Once deployment is complete login to Crosswork via: https://{VIP}:30603/#/logincontroller 
INFO: Cw Installer operation complete.

Note

 

If the installation fails due to a timeout, you should try rerunning the installation (step 13) without the -p option. This will deploy the VMs serially rather than in parallel.

If the installer fails for any other reason (for example, mistyped IP address), correct the error and rerun the install script.

If the installation fails (with or without the -p), open a case with Cisco and provide the .log files that were created during the install, to Cisco for review. The two most common reasons for the install to fail are: (a) password that is not adequately complex, and (b) errors in the template file.

What to do next

The time taken to create the cluster can vary based on the size of your deployment profile and the performance characteristics of your hardware. See Monitor the Installation to know how you can check the status of the installation.

Monitor the Installation

This section explains how to monitor and verify if the installation has completed successfully. As the installer builds and configures the cluster it will report progress. The installer will prompt you to accept the license agreement and then ask if you want to continue the install. After you confirm, the installation will progress and any possible errors will be logged in either installer.log or installer_tf.log. If the VMs get built and are able to boot, the errors in applying the operator specified configuration will be logged on the VM in the /var/log/firstboot.log.


Note

During installation, Cisco Crosswork will create a special administrative ID (virtual machine (VM) administrator, with the credentials that you provided in the template during the install. In case the installer is unable to apply the credentials, it creates the administrative ID with the username cw-admin, and the default password cw-admin). The administrative username is reserved and cannot be changed. The first time you log in using this administrative ID, you will be prompted to change the password. Data center administrators use this ID to log into and troubleshoot the Crosswork application VM. You will use it to verify that the VM has been properly set up.

The following is a list of critical steps in the process that you can watch for to be certain that things are progressing as expected:

  1. The installer uploads the crosswork image file (.ova file) to the vCenter data center.


    Note

    On running, the installer will upload the .ova file into the vCenter if it is not already present, and convert it into a VM template. After the installation is completed successfully, you can delete the template file from the vCenter UI (located under VMs and Templates) if the image is no longer needed.

  2. The installer creates the VMs, and displays a success message (e.g. "Creation Complete") after each VM is created.


    Note

    For VMware deployments, this activity can also be monitored from the vSphere UI.

  3. After each VM is created, it is powered on (either automatically when the installer completes, or after you power on the VMs during the manual installation). The parameters specified in the template are applied to the VM, and it is rebooted. The VMs are then registed by Kubernetes to form the cluster.

  4. Once the cluster is created and becomes accessible, a success message (e.g. "Crosswork Installer operation complete") will be displayed and the installer script will exit and return you to a prompt on the screen.

You can monitor startup progress using the following methods:

  • Using browser accessible dashboard: While the cluster is being created, you can monitor the setup process from a browser accessible dashboard. The URL for this grafana dashboard (in the format http://{VIP}:30602/d/NK1bwVxGk/crosswork-deployment-readiness?orgId=1&refresh=10s&theme=dark) is displayed once the installer completes. Please note that this URL is temporary and will be available only for a limited time (around 30 minutes). At the end of the deployment, the grafana dashboard will report a "Ready" status. If the URL is inaccessible, you can use the other methods described in this section to monitor the installation process.

    Figure 1. Crosswork Deployment Readiness

  • Using the console: You can also check the progress from the console of one of the hybrid VMs or by using SSH to the Virtual IP address. In the latter case, after logging in specify the cs-admin to be used, then switch to super user (sudo su - command) and run kubectl get nodes (to see if the nodes are ready) and kubectl get pods (to see the list of active running pods) commands. Repeat the kubectl get pods command until you see robot-ui in the list of active pods. At this point, you can try to access the Cisco Crosswork UI.

After the Cisco Crosswork UI becomes accessible, you can also monitor the status from the UI. For more information, see Log into the Cisco Crosswork UI.

Failure Scenario

In the event of a failue scenario (listed below), contact the Cisco Customer Experience team and provide the installer.log, installer_tf.log, and firstBoot.log files (there will be one per VM) for review:

  • Installation is incomplete

  • Installation is completed, but the VMs are not functional

  • Installation is completed, but you are directed to check /var/log/firstBoot.log or /opt/robot/bin/firstBoot.log file.

Known Limitations

These following scenarios are the caveats for installing the Cisco Crosswork using the cluster installer tool.

  • The vCenter host VMs defined must use the same network names (vSwitch) across all hosts in the data center.

  • The vCenter storage folders, i.e. datastores organized under a virtual folder structure, are not supported currently. Please ensure that the datastores referenced are not grouped under a folder.

  • Any VMs that are not created by the day 0 installer (for example, manually brought up VMs), cannot be changed either by the day 0 installer or via the Crosswork UI later. Similarly, VMs created via the Crosswork UI cannot be modified using the day 0 installer. When making modifications after the initial deployment of the cluster, ensure that you capture the inventory information. For more information, see the Manage Clusters chapter in the Crosswork Infrastructure 4.4 and Applications Administration Guide.

  • Crosswork does not support dual stack configurations, and all addresses for the environment must be either IPv4 or IPv6. However, vCenter UI provides a service where a user accessing via IPv4 can upload images to the IPv6 ESXi host. Cluster installer cannot use this service. Follow either of the following workarounds for IPv6 ESXi hosts:

    1. Upload the OVA template image manually, via the GUI and convert it to template.

    2. Run the cluster installer from an IPv6 enabled machine. To do this, configure the Docker daemon to map an IPv6 address into the docked container.

Troubleshoot the Cluster

By default, the installer displays progress data on the command line. The install log is fundamental in identifying the problems, and it is written into the /data directory.

Scenario

Possible Resolution

Missing or invalid parameters

The installer provides a clue as regards to the issue; however, in case of errors in the manfiest file HCL syntax, these can be misguiding. If you see "Type errors", check the formatting of the configuration manifest.

The manifest file can also be passed as a simple JSON file. Use the following converter to validate/convert: https://www.hcl2json.com/

Certificate Error

The ESXi hosts that will run the Crosswork application and Crosswork Data Gateway VM must have NTP configured, or the initial handshake may fail with "certificate not valid" errors.

Image upload takes a long time or upload is interrupted.

The image upload duration depends on the link and datastore performance and can be expected to take around 10 minutes or more. If an upload is interrupted, the user needs to manually remove the partially uploaded image file from vCenter via the vSphere UI.

vCenter authorization

The vCenter user needs to have authorization to perform the actions as described in Installation Requirements in VMware vCenter.

Floating VIP address is not reachable

The VRRP protocol requires unique router_id advertisments to be present on the network segment. By default, Crosswork uses the ID 169 on the management and ID 170 on the data network segments. A symptom of conflict, if it arises, is that the VIP address is not reachable. Remove the conflicting VRRP router machines or use a different network.

Crosswork VM is not allowing to log in

The password specified is not strong enough. Change the configuration manfiest and redeploy.

Error conditions such as:

Error: Error locking state: Error acquiring the state lock: resource temporarily unavailable

Error: error fetching virtual machine: vm not found

Error: Invalid index

These errors are common when re-running the installer after an initial run is interrupted (Control C, or TCP timeout, etc). Remediation steps are:

  1. Run the clean operation (./cw-installer.sh clean -m <your manifest here>) OR remove the VM files manually from the vCenter.

  2. Remove the state file (rm /data/crosswork-cluster.tfstate) and retry.

Deployment fails with: Failed to validate Crosswork cluster initialization.

The clusters' seed VM is either unreachable or one or more of the cluster VMs have failed to get properly configured.

  1. Check whether the VM is reachable, and collect logs from /var/log/firstBoot.log and /var/log/vm_setup.log

  2. Check the status of the other cluster nodes.

The VMs are deployed but the Crosswork cluster is not being formed.
A successful deployment allows the operator logging in to the VIP or any cluster IP address to run the following command to get the status of the cluster: 
sudo kubectl get nodes
A healthy output for a 3-node cluster is:
NAME                  STATUS   ROLES    AGE   VERSION
172-25-87-2-hybrid.cisco.com   Ready    master   41d   v1.16.4
172-25-87-3-hybrid.cisco.com   Ready    master   41d   v1.16.4
172-25-87-4-hybrid.cisco.com   Ready    master   41d   v1.16.4

In case of a different output, collect the following logs: /var/log/firstBoot.log and /var/log/vm_setup.log

In addition, for any cluster nodes not displaying the Ready state, collect: 
sudo kubectl describe node <name of node>

The following error is displayed while uploading the image:

govc: The provided network mapping between OVF networks and the system network is not supported by any host.

The Dswitch on the vCenter is misconfigured. Please check whether it is operational and mapped to the ESXi hosts.

The VMs take a long time to deploy

The disk load on the vCenter plays a major role in cloning VM. To ease loaded systems, it is possible to run the VM install operations in a serialized manner. On higher performance systems, run the deployment in parallel by passing the [-p] flag.

VMs deploy but install fails with Error: timeout waiting for an available IP address

Most likely cause would be an issue in the VM parameters provided or network reachability. Enter the VM host through the vCenter console. and review and collect the following logs: /var/log/firstBoot.log and /var/log/vm_setup.log

On cluster node failure, the VIP is not transferred to the remaining nodes

Ensure that switch or the vCenter Dswitch connected the VMs allows IP address movement (Allow Forged Transmits in vCenter). For more information, see VMware Settings.

When deploying on a vCenter, the following error is displayed towards the end of the VM bringup:

Error processing disk changes post-clone: disk.0: ServerFaultCode: NoPermission: RESOURCE (vm-14501:2000), ACTION (queryAssociatedProfile): RESOURCE (vm-14501), ACTION (PolicyIDByVirtualDisk)

Enable Profile-driven storage. Query permissions for the vCenter user at the root level (i.e. for all resources) of the vCenter.

Installer reports plan to add more resources than the current numbr of VMs

Other than the Crosswork cluster VMs, the installer tracks a couple of other meta-resources. Thus, when doing an installation of, say a 3-VM cluster, the installer may report a "plan" to add more resources than the number of VMs.

On running or cleaning, installer reports Error: cannot locate virtual machine with UUID "xxxxxxx": virtual machine with UUID "xxxxxxxx" not found

To resolve, remove the /data/crosswork-cluster.tfstate file.

The installer uses the tfstate file stored as /data/crosswork-cluster.tfstate to maintain the state of the VMs it has operated upon. If a VM is removed outside of the installer, that is through the vCenter UI, this state is out of synchronization.

Manual Installation of Cisco Crosswork using vCenter vSphere UI

This section explains the procedure to manually install Cisco Crosswork on VMware using the vCenter vSphere UI. The procedure needs to repeated for each node in the cluster.

The manual installation workflow is broken into two parts:

  1. Build the template

  2. Deploy the template

In the first part, you create a template. In the second part, you deploy the template as many times as needed to build the cluster of 3 Hybrid nodes (typically) along with any Worker nodes that your environment requires.


Note

If the template already exists and you need to rebuild or deploy a Worker node, you can directly go to deploying the template (the second part of this procedure).


Important

In case of manual installation of Crosswork Cluster, you must import a cluster inventory file (.tfvars file) to the Crosswork UI. The inventory file (a sample can be downloaded from the Crosswork UI) will contain information about the VMs in your cluster along with the data center parameters. Cisco Crosswork cannot deploy or remove VM nodes in your cluster until you complete this operation. For more information, see the Import Cluster Inventory topic in the Cisco Crosswork Infrastructure 4.4 and Applications Administration Guide.

Before you begin:

Build the template

Procedure

Step 1

Download the latest available Cisco Crosswork image file (*.ova) to your system.

Step 2

With VMware ESXi running, log into the VMware vSphere Web Client. On the left navigation pane, choose the ESXi host on which you want to deploy the VM.

Step 3

In the vSphere UI, go to Host > Configure > Networking > Virtual Switches and select the virtual switch. In the virtual switch, select Edit > Security, and configure the following DVS port group properties:

  • Set Promiscuous mode as Reject

  • Set MAC address changes as Reject

Confirm the settings and repeat the process for each virtual switch used in the cluster.

Step 4

Review and confirm that your network settings meet the requirements.

Step 5

Choose Actions > Deploy OVF Template.

Caution

 

The default VMware vCenter deployment timeout is 15 minutes. The total time needed to deploy the OVA image file may take much longer than 15 minutes, depending on your network speed and other factors. If vCenter times out during deployment, the resulting VM will be unbootable. To prevent this, we recommend that you document the choices they are going to make (such as IP address, gateway, DNS server, etc.) so that you can enter the information quickly and avoid any issues with the VMware configuration.

Step 6

The VMware Deploy OVF Template window appears, with the first step, 1 - Select an OVF template, highlighted. Click Choose Files to navigate to the location where you downloaded the OVA image file and select it. Once selected, the file name is displayed in the window.

Step 7

Click Next. The Deploy OVF Template window is refreshed, with 2 - Select a name and folder now highlighted. Enter a name and select the respective Datacenter for the Cisco Crosswork VM you are creating.

We recommend that you include the Cisco Crosswork version and build number in the name, for example: Cisco Crosswork 4.0 Build 152.

Step 8

Click Next. The Deploy OVF Template window is refreshed, with 3 - Select a compute resource highlighted. Select the host for your Cisco Crosswork VM.

Step 9

Click Next. The VMware vCenter Server validates the OVA. Network speed will determine how long validation takes. After the validation is complete, the Deploy OVF Template window is refreshed, with 4 - Review details highlighted.

Step 10

Review the OVF template that you are deploying. Note that this information is gathered from the OVF, and cannot be modified.

Step 11

Click Next. The Deploy OVF Template window is refreshed, with 5 - License agreements highlighted. Review the End User License Agreement and click the I accept all license agreements checkbox.

Step 12

Click Next The Deploy OVF Template window is refreshed, with 6 - Configuration highlighted. Choose the desired deployment configuration.

Figure 2. Select a deployment configuration

Note

 

If Cisco Crosswork is deployed using a single interface, then Cisco Crosswork Data Gateway must be deployed using a single interface as well (only recommended for lab deployments).

Step 13

Click Next. The Deploy OVF Template window is refreshed, with 7 - Select Storage highlighted. Choose the relevant option from the Select virtual disk format drop-down list. From the table, choose the datastore you want to use, and review its properties to ensure there is enough available storage.

Figure 3. Select Storage

Note

 

For production deployment, choose the Thick Provision Eager Zeroed option because this will preallocate disk space and provide the best performance. For lab purposes, we recommend the Thin Provision option because it saves disk space.

Step 14

Click Next. The Deploy OVF Template window is refreshed, with 8 - Select networks highlighted. From the Data Network and Management Network drop-down lists, choose an appropriate destination network.

Step 15

Click Next. The Deploy OVF Template window is refreshed, with 9 - Customize template highlighted.

  1. Expand the Management Network settings. Provide information for the IPv4 or IPv6 deployment (as per your selection).

  2. Expand the Data Network settings. Provide information for the IPv4 or IPv6 deployment (as per your selection).

    Figure 4. Customize template settings

    Note

     

    Data Network settings are not displayed if you have selected the IPv4 on a Single Interface or IPv6 on a Single Interface configuration.

  3. Expand the Deployment Credentials settings. Enter relevant values for the VM Username and Password.

    Note

     

    Use a strong VM Password (8 characters long, including upper & lower case letters, numbers, and one special character). Avoid using passwords similar to dictionary words (for example, "Pa55w0rd!") or relatable words (for example, C!sco123 or Cwork321!). While they satisfy the criteria, such passwords are weak and will result in the failure of VM setup. You are recommended to use a password with more characters and complex combinations.

  4. Expand the DNS and NTP Servers settings. According to your deployment configuration (IPv4 or IPv6), the fields that are displayed are different. Provide information in the following three fields:

    • DNS IP Address: The IP addresses of the DNS servers you want the Cisco Crosswork server to use. Separate multiple IP addresses with spaces.

    • DNS Search Domain: The name of the DNS search domain.

    • NTP Servers: The IP addresses or host names of the NTP servers you want to use. Separate multiple IPs or host names with spaces.

    Note

     

    The DNS and NTP servers must be reachable using the network interfaces you have mapped on the host. Otherwise, the configuration of the VM will fail.

  5. The default Disk Configuration settings should work for most environments. Change the settings only if you are instructed to by the Cisco Customer Experience team.

  6. Expand Crosswork Configuration and enter your legal disclaimer text (users will see this text if they log into the CLI).

  7. Expand Crosswork Cluster Configuration. Provide relevant values for the following fields:

    • VM Type:

      • Choose Hybrid if this is one of the 3 Hybrid nodes.

      • Choose Worker if this is a Worker node.

    • Cluster Seed node:

      • Choose True if this is the first VM being built in a new cluster.

      • Choose False for all other VMs, or when rebuilding a failed VM.

    • Crosswork Management Cluster Virtual IP: Enter the Management Virtual IP address and Management Virtual IP DNS name.

    • Crosswork Data Cluster Virtual IP: Enter the Data Virtual IP address. and the Data Virtual IP DNS name.

    • Initial node count: Default value is 3.

    • Initial leader node count: Default value is 3.

    • Location of VM: Enter the location of VM.

    • Installation type:

      • For new cluster installation: Do not select the checkbox.

      • Replacing a failed VM: Select the checkbox if this VM is being installed to replace a failed VM.

Step 16

Click Next. The Deploy OVF Template window is refreshed, with 10 - Ready to Complete highlighted.

Step 17

Review your settings and then click Finish if you are ready to begin deployment. Wait for the deployment to finish before continuing. To check the deployment status:

  1. Open a VMware vCenter client.

  2. In the Recent Tasks tab of the host VM, view the status of the Deploy OVF template and Import OVF package jobs.

Step 18

To finalize the template creation, select the host and right-click on the newly installed VM and select Template > Convert to Template. A prompt confirming the action is displayed. Click Yes to confirm. The template is created under the VMs and Templates tab in the vSphere Client UI.

This is the end of the first part of the manual installation workflow. In the second part, use the newly created template to build the cluster VMs.

Deploy the template

Procedure

Step 1

To build the VM, right-click on the newly created template and select New VM from This Template.

Step 2

The VMware Deploy From Template window appears, with the first step, 1 - Select a name and folder, highlighted. Enter a name and select the respective Datacenter for the VM.

Step 3

Click Next. The Deploy From Template window is refreshed, with 2 - Select a compute resource highlighted. Select the host for your Cisco Crosswork VM.

Step 4

Click Next. The Deploy From Template window is refreshed, with 3 - Select Storage highlighted. Choose Same format as source option as the virtual disk format (recommended).

If you are using a single data store: Select the data store you wish to use, and click Next.

Figure 5. Select Storage - single data store

If you are using two data stores (regular and high speed):

  • Enable Configure per disk option.

  • Select regular data store as the Storage setting for all the disks except disk 6.

  • Select high speed (ssd) data store as the Storage setting for disk 6.

    Note

     

    This disk must have 50 GB of free storage space.
    Figure 6. Select Storage - Configure per disk

  • Click Next.

Step 5

The Deploy From Template window is refreshed, with 4 - Select clone options highlighted. You can choose further clone options here.

(Optional) Perform the following steps to configure the disk, memory and Extensive Firmware Interface (EFI) boot settings:

Note

 

For non-lab environments, you need to reconfigure the hardware to use the proper amount of memory and CPU resources.

  • Choose Customize this virtual machine's hardware and click Next. The Edit Settings dialog box is displayed.

  • Under Virtual Hardware tab, enter the relevant values (see Crosswork Cluster VM Requirements) for CPU and Memory.

  • Under VM Options tab, expand Boot Options, select EFI as the Firmware, and check the Secure Boot checkbox.

    Note

     

    If you are only deploying Hybrid nodes, you do not need to change the hardware settings.

Step 6

Click Next. The Deploy From Template window is refreshed, with 5 - Customize vApp properties highlighted. The vApp properties from the template is already populated in this window. You need to check the following fields:

  • Cluster Seed node:

    • Choose True if this is the first VM being built in a new cluster.

    • Choose False for all other VMs, or when rebuilding a failed VM.

  • Management Network settings: Enter correct IP values for each VM in the cluster.

  • Data Network settings: Enter correct IP values for each VM in the cluster.

  • Crosswork Management Cluster Virtual IP: The Virtual IP will remain same for each cluster node.

  • Crosswork Data Cluster Virtual IP: The Virtual IP will remain same for each cluster node.

  • Deployment Credentials: Enter same deployment credentials for each VM in the cluster.

Note

 

(Optional) Use the Reservation field under the Virtual Hardware tab to set reservation for the VM's CPU allocation (in MHz) and memory profile (in MB).

Note

 

If this VM is being deployed to replace a failed VM, the IP and other settings must match the machine being replaced.

Step 7

Click Next. The Deploy From Template window is refreshed, with 6 - Ready to complete highlighted. Review your settings and then click Finish if you are ready to begin deployment.

Step 8

Repeat from Step 1 to Step 7 to deploy the remaining VMs in the cluster.

Step 9

You can now power on Cisco Crosswork VMs to complete the deployment process. The VM selected as the cluster seed node must be powered on first, followed by the remaining VMs (after a delay of few minutes). To power on, expand the host’s entry, click the Cisco Crosswork VM, and then choose Actions > Power > Power On.

The time taken to create the cluster can vary based on the size of your deployment profile and the performance characteristics of your hardware. See Monitor the Installation to know how you can check the status of the installation.

Note

 

If you are running this procedure to replace a failed VM, then you can check the status from the Cisco Crosswork GUI (go to Administration > Crosswork Manager and click on the cluster tile to check the Crosswork Cluster status.

Note

 

If you are using this process to build a new Worker node, no additional work is required after the node is powered on. The node will register with the existing Kubernetes cluster.

For more information on how the resources are allocated to the Worker node, see the Rebalance Cluster Resources topic in the Cisco Crosswork Infrastructure 4.5 and Applications Administration Guide.

What to do next
After you login to Crosswork UI, please import the cluster inventory file (.tfvars file). For more information, see the Import Cluster Inventory topic in the Cisco Crosswork Infrastructure 4.5 and Applications Administration Guide.

Install Crosswork Cluster on AWS EC2

This section describes how Cisco Crosswork is installed on Amazon Web Services Elastic Cloud Compute (AWS EC2). For more information on the prerequisites, see AWS EC2 Settings.


Attention

This document expects the user to be familiar with Amazon Web Services (AWS), Amazon EC2 concepts, and CloudFormation templates.

Install Cisco Crosswork on AWS EC2 using CloudFormation Template

Amazon CloudFormation (CF) allows you to create stacks via a structured template (.yaml file), referred to in this section as the CF template. The CF template contains parameter details of all your VMs, and the prerequisite Amazon Web Services (AWS) settings. During the process, the CF template is uploaded into the AWS UI and CloudFormation provisions the resources that are described in your template to install the Crosswork VMs.

The CloudFormation process is faster and less error-prone than the manual procedure to build the cluster.


Note

The terms 'stack' and 'instance' refers to cluster and VM respectively.

For more information on the CF template, see Sample CloudFormation template for installing Crosswork Cluster VMs on AWS EC2.


Important

The CF template (.yaml file) referenced in this section contains the details to install a Crosswork cluster with 3 VMs. Please note that it is only a sample, and you will create a different CF template according to your production preferences and execute it as per the steps mentioned in this section.

Before you begin

Make sure that you have met all the requirements specified in AWS EC2 Settings.

Procedure

Step 1

Log in to AWS and search for the CloudFormation service. The CloudFormation dashboard opens.

Step 2

Click Stacks from the side menu.

All existing stacks in the environment are displayed here.

Step 3

Click Create Stack > With new resources (standard).

The Create Stack window is displayed.

Step 4

In Step 1 - Specify template, select the following settings:

  1. Under Prepare template, select Template is ready.

  2. Under Template source, select Upload a template file.

  3. Click Choose file, and select your CF template (.yaml file).

    Note

     

    (Optional) Click View in Designer to view a visual representation of the execution flow in your CF template.

  4. Click Next.

Step 5

In Step 2 - Specify stack details, enter relevant values for the stack name and each parameter field, and click Next.

Note

 

The parameter field names visible in this window are defined by the parameters in your CF template. Generally, these fields include the AWS concepts mentioned in AWS EC2 Settings.

Step 6

In Step 3 - Configure stack options, enter the relevant values for the settings. Click Next to continue.

Note

 

The stack options are not exclusive for installing Crosswork and can be configured based on your production preferences.

Step 7

In Step 4- Review, review the settings you have selected.

Step 8

Click the acknowledgement checkbox at the bottom, and click Create stack to initiate the stack creation.

Step 9

Navigate to the Stacks window (see step 2), to see the list of stacks. Select the stack you configured (status will be CREATE_IN_PROGRESS).

The stack details are displayed on the right side of the window.

Step 10

In you stack window, click on the each tab to view the status of the creation. For example, the Outputs tab displays if the IP addresses are assigned correctly to each interface in your Crosswork cluster.

Note

 

Once a stack is created, export names are assigned to the VIP parameters (Data VIP and Management VIP), and they can be used to reference them in other CF templates. Changes to these export names are automatically updated downstream in the other stacks.

Step 11

Once the stack creation is completed (status will be CREATE_COMPLETE), click on the Resources tab, and click the Physical ID of the first instance in your stack (seed VM node).

The Instances window is displayed with details of the selected instance.

Step 12

Click Connect (top right corner). The Connect to instance window is displayed.

Step 13

Click on the EC2 serial console tab. Click Connect to connect to the console of the VM.

Step 14

Log in using the credentials specified in CWUsername and CWPassword parameters.

Step 15

Run the kubectl get nodes command to check if the VMs are available.

Install Crosswork Cluster on Amazon EC2 Manually

Follow the steps below to install Crosswork Cluster on Amazon EC2:

Before you begin

Make sure that you have met all the requirements specified in AWS EC2 Settings.


Attention

  • The Launch instance workflow offers a wide range of launch options that you can set based on your preferences. The following procedure only addresses the mandatory settings that must be configured for the successful deployment of your Crosswork instance.

  • The following procedure addresses the launching of Crosswork cluster with 3 VM instances. This procedure can also be used to launch a Worker VM node by setting the VMType as "Worker".

Procedure

Step 1

Download the Crosswork AMI (Amazon Machine Image) file from cisco.com to a location accessible from your Amazon Web Services (AWS).

Step 2

Prepare the user data for Crosswork Cluster VMs (see sample below):

Attention

 

This is a sample user data for a seed VM. Please use it as a reference to create user data based on your production preferences. You need to create similar user data for each VM in your cluster. 

<PropertySection>
              <Property oe:key="CWPassword" oe:value="${CNCSSHPassword}"/>
              <Property oe:key="CWUsername" oe:value="cw-admin"/>
              <Property oe:key="CwInstaller" oe:value="False"/>
              <Property oe:key="DNSv4" oe:value="169.254.169.253"/>
              <Property oe:key="DNSv6" oe:value="::0"/>
              <Property oe:key="DataIPv4Address" oe:value="10.10.2.201"/>
              <Property oe:key="DataIPv4Gateway" oe:value="10.10.2.1"/>
              <Property oe:key="DataIPv4Netmask" oe:value="255.255.255.0"/>
              <Property oe:key="DataIPv6Address" oe:value="::0"/>
              <Property oe:key="DataIPv6Gateway" oe:value="::1"/>
              <Property oe:key="DataIPv6Netmask" oe:value="64"/>
              <Property oe:key="DataVIP" oe:value="10.10.2.200"/>
              <Property oe:key="Deployment" oe:value="cw_ipv4"/>
              <Property oe:key="Disclaimer" oe:value="Cisco Crosswork"/>
              <Property oe:key="Domain" oe:value="cisco.com"/>
              <Property oe:key="InitMasterCount" oe:value="3"/>
              <Property oe:key="InitNodeCount" oe:value="3"/>
              <Property oe:key="IsSeed" oe:value="True"/>
              <Property oe:key="K8Orch" oe:value=""/>
              <Property oe:key="ManagementIPv4Address" oe:value="10.10.1.201"/>
              <Property oe:key="ManagementIPv4Gateway" oe:value="10.10.1.1"/>
              <Property oe:key="ManagementIPv4Netmask" oe:value="255.255.255.0"/>
              <Property oe:key="ManagementIPv6Address" oe:value="::0"/>
              <Property oe:key="ManagementIPv6Gateway" oe:value="::1"/>
              <Property oe:key="ManagementIPv6Netmask" oe:value="64"/>
              <Property oe:key="ManagementVIP" oe:value="10.10.1.200"/>
              <Property oe:key="NTP" oe:value="169.254.169.123"/>
              <Property oe:key="ManagerPeerIPs" oe:value="10.10.1.201 10.10.1.202 10.10.1.203"/>
              <Property oe:key="DataPeerIPs" oe:value="10.10.2.201 10.10.2.202 10.10.2.203"/>
              <Property oe:key="AwsIamRole" oe:value="SITEC2FullAccess"/>
              <Property oe:key="VMLocation" oe:value="default"/>
              <Property oe:key="VMType" oe:value="Hybrid"/>
              <Property oe:key="corefs" oe:value="20"/>
              <Property oe:key="ddatafs" oe:value="450"/>
              <Property oe:key="logfs" oe:value="10"/>
              <Property oe:key="ramdisk" oe:value="0"/>
              <Property oe:key="ssd" oe:value="50"/>
            </PropertySection>

Step 3

Log in to AWS and search for the EC2 service. The EC2 dashboard is displayed.

Step 4

Click on Launch Instance. The Launch an instance window is displayed.

Step 5

Under Name and tags, provide a name for the instance deployment. You can also provide additional tags, if you choose.

Step 6

Under Application and OS Images, click on the My AMI tab, select Owned by me. Browse the dropdown list and select the Crosswork AMI file that you downloaded earlier.

Step 7

Under Instance type, select the resource profile for your instance. In case of production deployments, you are recommended to select m5.8xlarge.

Step 8

Under Key Pair, create a new key pair or select the key pair you created earlier.

Step 9

Under Network Settings, click Edit and make the following changes:

  1. Under VPC, select the relevant VPC.

  2. Under Subnet, provide the Management subnet that you created earlier.

  3. Set Auto-assign public IP as Disabled.

  4. Under Firewall, create a security group or select the security group your created earlier.

  5. Under Advanced network configuration, enter relevant values for Network interface 1.

    • Description: Provide a description.

    • Primary IP: Specify the Management IP address of your VM.

  6. Click Add network interface, and enter relevant values for Network interface 2.

    • Description: Provide a description

    • Subnet: Select the Data subnet that you created earlier.

    • Security group: Select the security group you created earlier.

    • Primary IP: Specify the Data IP address of your VM.

    Note

     

    When you add a network interface, some fields (such as Subnet and Security group) may be prepopulated with values. Ensure that the values are consistent with the values you have selected earlier.

Step 10

Under Configure Storage, create the storage partitions for your instance. By default, three storage volumes added by AWS (click Advanced to view for more details). For Crosswork cluster, you need to add three additional custom storage volumes. Click on Add new volume, and specify the following values for each new volume:

Table 4. Configure Storage

Volume No.

Device Name

Size

Volume 4

/dev/sdc

10

Volume 5

/dev/sdd

450

Volume 6

/dev/sdm

10

Note

 

You are recommended to use either gp3 or gp2 as volume type for optimum experience.

Step 11

Under Advanced details, enter the following mandatory information:

  1. Under IAM instance profile, create a new IAM profile or browse the dropdown and select the IAM role you created earlier.

  2. Under Placement Group, create a new placement group (Cluster strategy) or browse the dropdown and select the placement group you created earlier.

  3. Set Metadata accessible field as Enabled.

  4. Set Metadata version field as V1 and V2 (token optional).

  5. Set Metadata response hop limit as 2.

  6. In the User data field, paste the template containing the parameters for your VM.

Note

 

If you are providing the VM parameters in a base64 encoded format instead of text, select the corresponding checkbox.

Step 12

Click Launch instance. A message is displayed about successfully initiating the launch of the instance.

Step 13

Repeat steps 3 to 12 for the remaining VM instances in your cluster.

Step 14

After all instances are launched, go to the EC2 dashboard, and click on Instances (on the side menu) to view the launched instances. The instances window is displayed. You can search for the instance using the name, attributes or tags.

Note

 

After all VM instances are launched correctly, it can take a while (minimum of 45 minutes) for the VMs to be ready and functional.

Step 15

To verify the installation, select your seed VM and click Connect (top right corner). The Connect to instance window is displayed.

Step 16

Click on the EC2 serial console tab. Click Connect to connect to the console of the VM.

Step 17

Log in using the credentials specified in CWUsername and CWPassword parameters.

Step 18

Run the kubectl get nodes command to check if the VMs are available.

Log into the Cisco Crosswork UI

Once the cluster activation and startup have been completed, you can check if all the nodes are up and running in the cluster from the Cisco Crosswork UI. Perform the following steps to log into the Cisco Crosswork UI and check the cluster health:


Note

If the Cisco Crosswork UI is not accessible, during installation, please access the host's console from the VMware or AWS EC2 UI to confirm if there was any problem in setting up the VM. When logging in, if you are directed to review the firstboot.log file, please check the file to determine the problem. If you are able to identify the error, rectify it and rerun the installer. If you require assistance, please contact the Cisco Customer Experience team.

Procedure

Step 1

Launch one of the supported browsers (see Supported Web Browsers).

Step 2

In the browser's address bar, enter:

https://<Crosswork Management Network Virtual IP (IPv4)>:30603/

or

https://[<Crosswork Management Network Virtual IP (IPv6)>]:30603/

Note

 

Please note that the IPv6 address in the URL must be enclosed with brackets.

Note

 

You can also log into the Crosswork UI using DNS name that was configured during the install.

The Log In window opens.

Note

 

When you access the Cisco Crosswork for the first time, some browsers display a warning that the site is untrusted. When this happens, follow the prompts to add a security exception and download the self-signed certificate from the Cisco Crosswork server. After you add a security exception, the browser accepts the server as a trusted site in all future login attempts. If you want to use a CA signed certificate, see the Manage Certificates section in the Cisco Crosswork Infrastructure 4.4 and Applications Administrator Guide.

Step 3

Log into the Cisco Crosswork as follows:

  1. Enter the Cisco Crosswork administrator username admin and the default password admin.

  2. Click Log In.

  3. When prompted to change the administrator's default password, enter the new password in the fields provided and then click OK.

    Note

     

    Use a strong VM Password (minimum 8 characters long, including upper & lower case letters, numbers, and one special character). Avoid using passwords similar to dictionary words (for example, "Pa55w0rd!") or relatable words (for example, C!sco123 or Cwork321!). You are recommended to use a password with more characters and complex combinations.

The Crosswork Manager window is displayed.

Step 4

(Optional) Click on the Crosswork Health tab, and click on the Crosswork Infrastructure tile to view the health status of the microservices running on Cisco Crosswork.