--- title: "Configuring H/W Sensor Management - Warm Standby System" slug: "configuring-h-w-sensor-management-warm-standby-system" updated: 2026-11-11T19:02:34Z published: 2026-11-11T19:02:34Z canonical: "docs.crossworkassurance.cisco.com/configuring-h-w-sensor-management-warm-standby-system" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.crossworkassurance.cisco.com/llms.txt > Use this file to discover all available pages before exploring further. # Configuring H/W Sensor Management - Warm Standby System ## Introduction This article provides the configuration values and verification steps for deploying Hardware Sensor Management (H/W SM) in a Warm Standby Redundancy environment with a worker VM instance. Use this article alongside the [Replicated Cluster with H/W Sensor Management Worker Deployment](/latest/docs/replicated-cluster-with-h-w-sensor-management-worker-deployment) article, which contains the broader Crosswork Assurance deployment workflow and additional background details. In a warm standby setup, the database is mirrored to the secondary system at regular intervals. Failover is initiated manually. ### Initial Setup The initial setup for Warm Standby Redundancy is as follows: - The primary site normally manages devices. It periodically sends a backup of its data store to the secondary site. - The secondary site is in standby mode, ready to replace the primary site in case of failure. - A cleanup task at midnight deletes backup files older than seven days in the `/home/skylight/backups/` directory (configurable in the Crosswork Assurance Admin Console Web GUI). - The Docker host of the H/W Sensor Management secondary site must have enough disk space to store the backup files. ### Details for Configuring H/W Sensor Management on the Crosswork Assurance Admin Console Web GUI #### Host Information | Field | Value | | --- | --- | | Enable H/W Sensor Management | **Enabled** | | Host Information | **Enabled** | | Show the prerequisites | Select to display the collector host requirements. | | Host IP Address(es) | IP address of the H/W SM worker — Host A on the first line, Host B on the second line. Each line supports IPv4 only. | | SSH Private Key | Upload the `skylight` private key file. This private key is used for both H/W and SM workers. | | Skylight User Password | Password for the skylight user (required for sudo access). **Note:** The skylight password must be the same on both hosts. | | Enable Dual-Stack | - **Check:** Sensor Management connects to devices on both IPv4 and IPv6 networks. - **Uncheck:** Sensor Management connects to devices on IPv4 networks only. | #### High Availability | Field | Value | | --- | --- | | High Availability | **Enable** | | HA Mode | Warm Standby (periodic DB backup transfer, manual failover) | | DB Backup Remote Directory (Host B) | Directory on Host B where DB backup files pushed from Host A are stored. This directory is created automatically on Host B if it does not already exist Default value: **/home/skylight/backups** | | DB Backup Frequency | How often the DB backup is pushed from Host A to Host B over SFTP. - **Every** **15 minutes**: The data store will be backed up every 15 minutes. - **Every hour**: If you select **hour** as the frequency, an additional field appears. It allows you to set the minute (0 to 59) at which the backup should be done. The data store will be backed up every hour at the selected minute. - **Every day**: If you select **day** as the frequency, two additional fields appear. The extra fields allow you to set the hour (0 to 23) and minute (0 to 59) at which the backup should be done. The data store will be backed up once a day at the hour and minute you select. - **Every week**: If you select **week** as the frequency, three additional fields appear. The extra fields allow you to set the day (Sunday to Saturday), hour (0 to 23), and minute (0 to 59) at which the backup should be done. The data store will be backed up once a week on the day and at the hour and minute you select. - **Every month**: If you select **month** as the frequency, three additional fields appear. The extra fields allow you to set the day of the month (1 to 31), hour (0 to 23), and minute (0 to 59) at which the backup should be done. The data store will be backed up once a month on the day and time you select. - **Never**: If you select **Never** as the frequency, the data store will not be backed up automatically. **Min:** You set the minutes you wish up to 59 by using the drop-down menu and making the selection. **H:** You set the H you wish from 0 to 23 by using the drop-down menu and making the selection. Default value: **Every** **15 minutes (Recommended)** **Warning:** Changes made in the Admin Console apply to the Sensor Management database backup schedule. Changes made in the Sensor Management UI do not update the Admin Console setting, so the two screens may display different schedules. | | DB Backup Retention (days) | Number of days: **1 - 10** Default value: **7** | | Active Site | **Site A (Host A)**: Select if Host A is the Primary site **Site B (Host B)**: Select if Host B is the Primary site Default value: **Site A (Host A)** | | Manual Failover Trigger | Select the target **Active Site**, increase this value, and deploy the configuration. Failover stops services on the outgoing site and restores the latest backup to the target site. Increase the value each time you want to trigger a failover. Reusing the same value will not trigger another failover. **Default value: 0** | #### Application Configuration | Field | Value | | --- | --- | | Application Configuration | **Enabled** | | Application Version | `25.07.1-LTS-HYBRID` | | Deployment Selection | **Install** | | Device profile (max devices) | 5K | | Session profile (max sessions) | 125K | | User profile (max users) | 250 | | FIPS mode | **Enabled**: Sensor Management manages FIPS devices. **Disabled**: Sensor Management manages non-FIPS devices. Default: **Enabled** | #### H/W Sensor Collector | Field | Value | | --- | --- | | Sensor Collector | Disabled unless required (when enabled it needs a personal access token) | Refer to [Configuring the Sensor Collector for H/W and S/W Sensor Management](/latest/docs/configuring-the-sensor-collector-for-h-w-and-s-w-sensor-management) for details. ### Deploy and Verify H/W SM Worker The H/W SM worker is deployed together with Crosswork Assurance. Pre-flight checks include the H/W SM worker checks (SSH as `skylight`, sudo, firewalld/SELinux, disk, and other prerequisites); resolve any failures before deploying. Follow the progress on the Controller node: 1. Access the root user or run `sudo su -` if the account has sudo privileges. 2. Configure to use kubectl command, enter: ``` export KUBECONFIG="/var/lib/embedded-cluster/k0s/pki/admin.conf" export PATH="$PATH:/var/lib/embedded-cluster/bin" ``` 1. Check pods and job log, enter: ``` kubectl -n pca get jobs,pods | grep hw-sm kubectl -n pca logs job/ ``` When the installation succeeds, the `hw-sm-app-deploy` log ends with: ``` The installation of Cisco Crosswork Assurance Sensor Management ... is complete ``` Then verify: | Check | Command | Expected Result | | --- | --- | --- | | Worker joined | `kubectl get nodes` | The SM worker is `Ready` alongside the Kubernetes node(s) | | H/W SM containers | On the worker: `docker ps` | `so-core`, `so-med`, `so-nbi`, `so-mysql`, `so-syslog` all `healthy` | | H/W SM CLI | On the worker, as `skylight`: `/usr/bin/smcli.sh` | SM management menu | | Admin Console | Dashboard | **Ready**, Cluster State **Up to date** | The H/W SM files are under `/home/skylight/so/` on the worker. **© 2026 Cisco and/or its affiliates. All rights reserved.** For more information about trademarks, please visit: [Cisco trademarks](https://www.cisco.com/c/en/us/about/legal/trademarks.html)[](https://www.cisco.com/c/en/us/about/legal/trademarks.html) For more information about legal terms, please visit: [Cisco legal terms](https://www.cisco.com/c/en/us/about/legal/terms-conditions.html)