--- title: "Configuring H/W Sensor Management - Hot Standby System" slug: "configuring-h-w-sensor-management-hot-standby-system" updated: 2026-11-11T19:02:24Z published: 2026-11-11T19:02:24Z canonical: "docs.crossworkassurance.cisco.com/configuring-h-w-sensor-management-hot-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 - Hot Standby System ## Introduction This article provides the configuration values and verification steps for deploying Hardware Sensor Management (H/W SM) in a **Hot Standby** Redundancy environment with two worker VM instances. 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 hot standby setup, the data store is replicated to the secondary system continuously at block level. Failover can be automatic. For manual failover with periodic backups instead, see [Configuring H/W Sensor Management - Warm Standby System](/latest/docs/configuring-h-w-sensor-management-warm-standby-system) ### Initial Setup The initial setup for Hot Standby Redundancy is as follows: - Two H/W SM hosts run as **Site A (Host A)** and **Site B (Host B)**. One site is **Active** and manages devices; the other is **Passive**, ready to replace the Active site in case of failure. - The H/W Sensor Management data is replicated between the sites at block level (DRBD) over a dedicated replication network. - A monitoring link between the sites detects failures. With **Automatic Failover** enabled, the Passive site takes over without manual action. - You can also switch the active site manually, and suspend redundancy for maintenance. ### Prerequisites Specific to Hot Standby Both hosts must also meet the [H/W Sensor Management Worker Node Requirements](/latest/docs/replicated-cluster-with-h-w-sensor-management-worker-deployment#hw-sensor-management-worker-node-requirements) and the `skylight` user requirements on the [Replicated Cluster with H/W Sensor Management Worker Deployment](/latest/docs/replicated-cluster-with-h-w-sensor-management-worker-deployment) article. In addition: | | Requirement | | --- | --- | | 1 | Each host has **three network interfaces**: management, replication, and monitoring. The interface **names must be the same on both hosts**, because the Admin Console takes one interface list for both. | | 2 | Each host has a **dedicated raw block device** for replication, of the same size on both hosts. **The device is reformatted during setup. Do not use the OS disk.** | | 3 | The **DRBD Proxy license file** contains the MAC address of the **management interface of both hosts**. | | 4 | Firewall ports are open on both hosts: `7788/tcp`, `7789/tcp`, `6969/tcp`, `5405/udp`, `5406/udp`, in addition to the worker ports on the parent page | | 5 | The `skylight` password is **the same on both hosts**, and the same SSH key is installed on both. | | 6 | If **Enable Dual-Stack** is checked, the management interface of each host has an IPv6 address. Otherwise the preflight checks `COMPANION_ADDRESS` and `COMPANION_CONNECTIVITY` fail. | Warning: confirm the disk before every deploy. Linux can enumerate disks in a different order after a reboot (for example, `/dev/sda` and `/dev/sdb` swapping). To avoid this, enter the stable path of the disk (`/dev/disk/by-id/...`) instead of `/dev/sdX`; the Admin Console accepts both. Either way, run `lsblk` on **each host** immediately before deploying and check that the configured device is the empty replication disk, not the disk that holds `/`. ### Details for Configuring H/W Sensor Management on the Crosswork Assurance Admin Console Web GUI Complete **all** groups before you save the configuration for the first time. #### Host Information | | Field | Value | Note | | --- | --- | --- | --- | | 1 | Enable H/W Sensor Management | **Enabled** | | | 2 | Host Information | **Enabled** | | | 3 | Show the prerequisites | | Select to display the Docker host requirements. | | 4 | Host IP Address(es) | Host A on the first line, Host B on the second line | IP address of the H/W SM workers. Each line supports IPv4 only. | | 5 | SSH Private Key | `skylight` private key file | The same key is used for both hosts. | | 6 | Skylight User Password | Password of the `skylight` user | Used for sudo access. It must be the same on both hosts. | | 7 | Enable Dual-Stack | **Check** or **Uncheck** | **Check:** H/W Sensor Management can connect to devices on both IPv4 and IPv6 networks. Each host needs an IPv6 address on the management interface. **Uncheck:** H/W Sensor Management can connect to devices on IPv4 networks only. | #### High Availability | | Field | Value | Note | | --- | --- | --- | --- | | 1 | High Availability | **Enabled** | | | 2 | HA Mode | **Hot Standby** (block-level data replication, automatic or manual failover) | | | 3 | Show the prerequisites | | Select to display the hot standby requirements. | | 4 | Network Interfaces (Host A / Host B) | `management:<interface>``replication:<interface>``monitoring:<interface>` (one per line) | One `role:interface` per line. Use the same interface names on both hosts. For example:`management:ens192 replication:ens224 monitoring:ens256` | | 5 | Host A (Site A) Raw Block Device | `/dev/disk/by-id/<disk-id>` (recommended) or `/dev/sdX` | Replication disk on Host A. **The disk is reformatted.** | | 6 | Host A Block Device Acknowledgment | **Checked** | Confirms that the Host A device can be erased. Required. | | 7 | Host B (Site B) Raw Block Device | `/dev/disk/by-id/<disk-id>` (recommended) or `/dev/sdX` | Replication disk on Host B, in the same format. **The disk is reformatted.** | | 8 | Host B Block Device Acknowledgment | **Checked** | Confirms that the Host B device can be erased. Required. | | 9 | Automatic Failover | **Enabled** or **Disabled** | **Enabled:** the Passive site takes over automatically when the Active site fails. **Disabled:** failover is manual only. Default: **Enabled**. | | 10 | Preferred Site | **None**, **Site A**, or **Site B** | The site that should be Active when both are healthy. Default: **None**. | | 11 | HA License File | DRBD Proxy license file | Upload the file. It must contain the management MAC address of both hosts. | | 12 | Suspend Redundancy Acknowledgment | **Checked** | Allows suspending redundancy. | | 13 | Suspend Redundancy (Maintenance Mode) | Number, default **0** | Increase the number and deploy to suspend redundancy. | | 14 | Resume Redundancy | Number, default **0** | Increase the number and deploy to resume redundancy. | #### Application Configuration | | Field | Value | | --- | --- | --- | | 1 | Application Configuration | **Enabled** | | 2 | Application Version | `25.07.1-LTS-HYBRID` (default value; cannot be changed) | | 3 | Deployment Selection | **Install** (default value; cannot be changed) | | 4 | Device profile (max devices) | 5K (default value; cannot be changed) | | 5 | Session profile (max sessions) | 125K (default value; cannot be changed) | | 6 | User profile (max users) | 250 (default value; cannot be changed) | | 7 | FIPS mode | **Enabled**: Sensor Management can manage FIPS devices. **Disabled**: Sensor Management can manage non-FIPS devices. Default: **Enabled** | Leave **⚠ Reset Worker Node(s) (Destructive)** off. #### H/W Sensor Collector 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 Workers The H/W SM workers are deployed together with Crosswork Assurance in a single deployment. Pre-flight checks include the H/W SM worker checks (SSH as `skylight`, sudo, firewalld/SELinux, disk, and other prerequisites) and the HA checks below; resolve any failures before deploying. #### 1. Preflight Checks Some HA checks are expected warnings before the first deployment, because the services they test are not installed yet: | | Check | Meaning | | --- | --- | --- | | 1 | `HA_MAC_LICENSE` | The license file does not contain the management MAC of one of the hosts. **Fix it.** The check may also warn before the first deploy if the license file is not mounted yet. | | 2 | `HA_BLOCK_DEVICE`, `HA_BLOCK_DEVICE_SIZE_MATCH` | The disk is missing, or the two disks differ in size. **Fix it.** These checks can also report "could not read" or "0 bytes" when run without root; verify the sizes with `sudo blockdev --getsize64 <device>` on each host. | | 3 | `HA_PORT_*` | The HA ports are not listening yet. This is expected before the first deploy. Confirm that the ports are open in the firewall. | | 4 | `COMPANION_ADDRESS`, `COMPANION_CONNECTIVITY` | Dual-Stack is checked but the management interface has no IPv6 address. Add an address or uncheck **Enable Dual-Stack**. | #### 2. Follow the Deployment 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 ``` The H/W SM jobs run in a chain. The HA jobs run last, in this order: 1. `ha-hot-license-import` 2. `ha-hot-block-device-prep` 3. `ha-hot-reconfigure` The full deployment can take about one hour or more (typical time by sizing). One `Error` pod per `hw-sm-app-deploy` job is a known harmless retry. #### 3. Verify the Deployment **Important:** the `ha-hot-reconfigure` job can print `HA_ACTIVATION_FAILED` and still finish as **Complete**. Always read its log. | | Check | Command | Expected result | | --- | --- | --- | --- | | 1 | HA reconfigure job | `kubectl -n pca logs job/<ha-hot-reconfigure-job-name>` | The log ends with `Global Status : Started`. It must not contain `HA_ACTIVATION_FAILED` or `Global Status : Stopped`. | | 2 | Workers joined | `kubectl get nodes` | The Controller and both H/W SM workers are `Ready` | | 3 | H/W SM containers on the **Active** site | On the worker, as `skylight`: `docker ps` | `so-core`, `so-med`, `so-nbi`, `so-mysql`, `so-syslog`, and `so-ha` are running and `healthy` | | 4 | H/W SM containers on the **Passive** site | On the worker, as `skylight`: `docker ps` | Only `so-ha` and `so-syslog` run. This is expected. | | 5 | HA state | `kubectl -n pca describe pod hw-sm-status-host-<a/b>`, section "Published vendor HA view" | One site Active, the other Passive, replication up | | 6 | H/W SM CLI | On the Active worker, as `skylight`: `/usr/bin/smcli.sh` | SM management menu | | 7 | Admin Console | Dashboard | **Ready**, Cluster State **Up to date**. See the known limitations below. | The H/W SM files are under `/home/skylight/so/` on each worker. The HA log is `/home/skylight/so/logs/hamon/hamon.log` (root-owned). ### Operations - **Switch the active site manually:** increase **Manual Switch Trigger**, deploy. - **Suspend redundancy for maintenance:** check **Suspend Redundancy Acknowledgment**, increase **Suspend Redundancy (Maintenance Mode)**, deploy. To resume, increase **Resume Redundancy** and deploy. - **Reset the workers:** see [Resetting the H/W SM Worker Node](/latest/docs/resetting-the-h-w-sm-worker-node). The reset runs on **both** hosts, removes all Sensor Management data, and has no backup. Enter a Reset Trigger number higher than any used before. ### Known Limitations - **Console shows "Unavailable":** the Admin Console can show the application as Unavailable while HA is healthy, because the `hw-sm-status-host-b` deployment is never Ready while Site B is Passive. **© 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)