---
title: "Resetting the H/W SM Worker Node"
slug: "resetting-the-h-w-sm-worker-node"
updated: 2026-11-11T19:02:24Z
published: 2026-11-11T19:02:24Z
canonical: "docs.crossworkassurance.cisco.com/resetting-the-h-w-sm-worker-node"
---

> ## 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.

# Resetting the H/W SM Worker Node

## Introduction

This article describes how to reset the Hardware Sensor Management (H/W SM) worker nodes of a Crosswork Assurance replicated system, so that the workers can be redeployed from a clean state. It applies to the Non-High-Availability, Warm Standby, and Hot Standby systems. 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.

              Destructive, no backup, cannot be undone

              

The reset removes the H/W Sensor Management application and all its data, removes k0s, deletes the Kubernetes node object, and reboots the workers.

**Do not use** *Removing Nodes from the Cluster* from the [Replicated Cluster with H/W Sensor Management Worker Deployment](/latest/docs/replicated-cluster-with-h-w-sensor-management-worker-deployment) article to reset an H/W SM worker.

## What the Reset Does

The reset runs on **every host** in **Host IP Address(es)**: one host for a Non-HA system, two hosts (Site A and Site B) for Warm Standby and Hot Standby. On each host, it:

- Stops the H/W Sensor Management services and removes all Docker containers, images, and volumes;
- Unmounts and empties `/home/skylight` (the `.ssh` directory is kept, so the `skylight` SSH key still works), and removes the H/W Sensor Management backup cron entry of the `skylight` user;
- Stops and removes k0s (`/etc/k0s`, `/var/lib/k0s`);
- Reboots the host after about 60 seconds.

In the cluster, it also deletes the H/W SM objects (label `app.kubernetes.io/part-of=hw-sm-external`: jobs, deployments, configmaps, and services in namespace `pca`) and the Kubernetes node object of each worker.

It does **not** touch the Controller node, the Admin Console configuration, the SSH key, the `skylight` password, or the HA license file stored in the Admin Console.

## Before You Reset

|  | Check |
| --- | --- |
| 1 | You are resetting the right system. The automated reset applies to **all** configured hosts; there is no per-host option. |
| 2 | You do not need the H/W Sensor Management data. Export what you need first. **Warm Standby:** the backup files in `/home/skylight/backups` on Host B are deleted too. |
| 3 | Every host is reachable over SSH as `skylight` with the configured key, and the `skylight` sudo password is correct. The automatic reset connects the same way as the deployment. |
| 4 | **Hot Standby:** note the replication disk of each host (`lsblk`, preferably the `/dev/disk/by-id/...` path) before you reset. After the reboot, check again before you deploy, because disk names can change. |
| 5 | **Reset Trigger:** note the last number used. The next reset needs a **higher** number. |

## Details for Resetting H/W Sensor Management on the Crosswork Assurance Admin Console Web GUI

Go to **Config → H/W Sensor Management**.

### Reset Fields

|  | Field | Value | Note |
| --- | --- | --- | --- |
| 1 | ⚠ Reset Worker Node(s) (Destructive) | **Check** to enable the reset | Leave it **unchecked** during normal deployments. |
| 2 | Reset Method | **Automatic** or **Manual** | Use **one** method at a time. Default: **Automatic**. |
| 3 | Reset Trigger | Number, default **0** | Automatic only. Enter a number **higher than any used before** and deploy to run exactly one reset. Saving the same number again does nothing. |

|  | Reset Method | Behavior |
| --- | --- | --- |
| 1 | **Automatic** (Admin Console-triggered Job) | The Admin Console runs a reset job for every configured host when you deploy. |
| 2 | **Manual** (copy/paste commands, run yourself) | The Admin Console shows the commands. You run them yourself. Nothing else in the cluster is changed or restarted by the deployment. |

### Automatic Reset

1. In **H/W Sensor Management**, check **⚠ Reset Worker Node(s) (Destructive)**.
2. Set **Reset Method** to **Automatic**.
3. Enter a new number in **Reset Trigger**.
4. Save the configuration, run the pre-flight checks, and deploy.

The reset jobs `hw-sm-worker-node-reset-<n>` (one per host) take about 1 to 2 minutes. Each host reboots about 60 seconds after its reset finishes.

### Manual Reset

Use this method when the Admin Console cannot reach a host, or when you want to control each step. The Admin Console shows the exact commands for your hosts under **Reset Method = Manual**. Copy them from there.

After all workers reboot, set **Deployment Selection** to **Install** and deploy again.

## Redeploy After the Reset

1. Uncheck **⚠ Reset Worker Node(s) (Destructive)**. Leave the **Reset Trigger** number as it is.
2. Set **Deployment Selection** to **Install** (in **Application Configuration**). Refer to these articles for details:
  - [Configuring H/W Sensor Management - Non-High-Availability System](/latest/docs/configuring-h-w-sensor-management-non-high-availability-system)
  - [Configuring H/W Sensor Management - Warm Standby System](/latest/docs/configuring-h-w-sensor-management-warm-standby-system)
  - [Configuring H/W Sensor Management - Hot Standby System](/latest/docs/configuring-h-w-sensor-management-hot-standby-system)

**© 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)