> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-cpu-hog.md).

# VMware CPU hog

VMware CPU hog is a VMware chaos fault that drives CPU utilization to `CPU_LOAD` percent across `CPU_CORES` cores on the Linux VM `VM_NAME` (hosted in vCenter) for `TOTAL_CHAOS_DURATION` seconds, then stops the stress workload. The fault uses VMware Tools (Guest Operations API) to run the stress workload inside the guest as `VM_USER_NAME` and reverts cleanly at the end.

Use this fault to test how a workload on a VMware-hosted VM behaves when compute headroom shrinks: whether latency stays inside the SLA, whether the OS scheduler keeps critical processes responsive, whether vSphere DRS responds correctly, and whether monitoring detects CPU saturation within the alerting SLA.

{% hint style="info" %}
**RUN YOUR FIRST EXPERIMENT**

If you have not configured the chaos infrastructure yet, go to [Quickstart](/resilience-testing/chaos-engineering/new-to-chaos-engineering/quickstart.md) to install the chaos infrastructure and run an experiment end to end.
{% endhint %}

***

### Use cases <a href="#use-cases" id="use-cases"></a>

Run this fault when you want to answer concrete questions like:

* **CPU pressure on a vSphere VM:** When CPU utilization climbs, does application latency stay inside the SLA?
* **DRS migration:** Does vSphere DRS migrate the VM to a less-loaded host when sustained CPU pressure persists?
* **Co-tenant impact:** Do other VMs on the same ESXi host degrade because of the CPU steal time?
* **Monitoring fidelity:** Do vCenter performance counters and downstream alerts fire inside the alerting SLA?

***

### Prerequisites <a href="#prerequisites" id="prerequisites"></a>

* **Kubernetes version:** 1.21 or later for the chaos infrastructure cluster.
* **vCenter reachable:** The chaos infrastructure can reach `GOVC_URL` over port 443.
* **VMware Tools running on the guest:** Verify with `vmware-toolbox-cmd -v` inside the VM.
* **Stress binary installed inside the guest:** Go to [VMware Linux binary installation](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/binary-installation.md) to install the CPU stress prerequisite (`stress-ng` and `pkill`).
* **vCenter chaos role:** The vCenter user (`GOVC_USERNAME`) is mapped to the chaos role described in [VMware permissions](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/permissions.md).

***

### Supported environments <a href="#supported-environments" id="supported-environments"></a>

| Platform                                                             | Support status                                                                                                                                  |
| -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| Linux VMs hosted on vSphere / vCenter (any distro with VMware Tools) | Supported                                                                                                                                       |
| Linux VMs without VMware Tools                                       | Not supported (the fault drives the guest via Guest Operations)                                                                                 |
| Windows VMs                                                          | Not supported (use [VMware Windows CPU hog](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-cpu-stress.md)) |

***

### Permissions required <a href="#permissions-required" id="permissions-required"></a>

Two layers of permissions apply.

**On vCenter.** Map `GOVC_USERNAME` to the chaos role described in [VMware permissions](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/permissions.md). For this Basic fault, the role needs at minimum:

* Virtual machine → Guest operations → Program execution, Modifications, Queries.

**On the guest OS.** `VM_USER_NAME` must be able to execute the CPU stress binary and (on abort) run `pkill`. For non-root accounts, configure `sudo` for the stress binary if needed.

***

### Authentication <a href="#authentication" id="authentication"></a>

Two credential sets are required.

| Layer                   | Tunables                                                      |
| ----------------------- | ------------------------------------------------------------- |
| vCenter (control plane) | `GOVC_URL`, `GOVC_USERNAME`, `GOVC_PASSWORD`, `GOVC_INSECURE` |
| Guest OS (target VM)    | `VM_USER_NAME`, `VM_PASSWORD`                                 |

Store each credential as a text secret in [Harness Secret Manager](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md) and reference the secret identifier when configuring the experiment.

Set `GOVC_INSECURE=true` only if your vCenter certificate is self-signed and not yet trusted.

***

### Fault tunables <a href="#fault-tunables" id="fault-tunables"></a>

Configure the following fault parameters when you add VMware CPU hog to an experiment in Chaos Studio. Defaults are shown for reference.

**Required parameters**

| Tunable        | Description                                     | Default    |
| -------------- | ----------------------------------------------- | ---------- |
| `VM_NAME`      | Name of the target VM as it appears in vCenter. | (required) |
| `VM_USER_NAME` | OS user account on the target VM.               | (required) |
| `VM_PASSWORD`  | Password for `VM_USER_NAME`.                    | (required) |

**Stress parameters**

| Tunable     | Description                                                  | Default |
| ----------- | ------------------------------------------------------------ | ------- |
| `CPU_CORES` | Number of CPU cores to stress.                               | `2`     |
| `CPU_LOAD`  | Target CPU utilization percentage per stressed core (0-100). | `100`   |

**Chaos parameters**

| Tunable                | Description                                                                                                                                                                                                      | Default    |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TOTAL_CHAOS_DURATION` | Total duration of the fault in seconds.                                                                                                                                                                          | `30`       |
| `CHAOS_INTERVAL`       | Delay in seconds between successive iterations when running for more than one cycle.                                                                                                                             | `10`       |
| `SEQUENCE`             | Order in which multiple targets are stressed: `parallel` or `serial`.                                                                                                                                            | `parallel` |
| `RAMP_TIME`            | Wait period in seconds before and after the fault. Go to [ramp time](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/common-tunables-for-all-faults.md#ramp-time) to read how it is applied. | `0`        |

**vCenter authentication**

| Tunable         | Description                                                             | Default |
| --------------- | ----------------------------------------------------------------------- | ------- |
| `GOVC_URL`      | vCenter server URL (without scheme), for example `vcenter.example.com`. | `""`    |
| `GOVC_USERNAME` | vCenter user mapped to the chaos role.                                  | `""`    |
| `GOVC_PASSWORD` | Password for `GOVC_USERNAME`.                                           | `""`    |
| `GOVC_INSECURE` | Skip SSL certificate verification when set to `true`.                   | `true`  |

Tunables that apply to every fault are documented in [common tunables for all faults](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/common-tunables-for-all-faults.md).

***

### Fault execution in brief <a href="#fault-execution-in-brief" id="fault-execution-in-brief"></a>

Authenticates to vCenter (`GOVC_URL`), opens a Guest Operations session on `VM_NAME` as `VM_USER_NAME`, launches a CPU stress workload that targets `CPU_CORES` at `CPU_LOAD` percent for `TOTAL_CHAOS_DURATION` seconds, then terminates the workload.

***

### Expected behavior during fault execution <a href="#expected-behavior-during-fault-execution" id="expected-behavior-during-fault-execution"></a>

* CPU utilization on the target VM climbs to `CPU_LOAD` percent on `CPU_CORES` cores for the duration.
* Application latency may grow in proportion to the load.
* vCenter performance counters (`cpu.usage.average`) reflect the spike on the VM and may show steal time impact on co-tenant VMs.
* After the duration ends, the stress workload exits and CPU utilization returns to baseline.

{% hint style="info" %}
**WHEN THE FAULT ENDS**

The chaos pod stops the stress workload via Guest Operations. CPU utilization returns to baseline within seconds.
{% endhint %}

#### Signals to watch <a href="#signals-to-watch" id="signals-to-watch"></a>

* **VM CPU:** Use a [Prometheus probe](/resilience-testing/chaos-engineering/use-chaos-engineering/probes/apm-probes.md) on `node_cpu_seconds_total` from a node exporter inside the VM.
* **Application latency:** Use an [HTTP probe](/resilience-testing/chaos-engineering/use-chaos-engineering/probes/http-probe.md) on a user-visible endpoint.

***

### Verify the fault execution effect <a href="#verify-the-fault-execution-effect" id="verify-the-fault-execution-effect"></a>

1. **Inspect vCenter performance counters.**

   In vCenter UI, open the VM → Monitor → Performance, switch to **CPU** view. You should see a spike during the chaos window.
2. **SSH into the VM and run `top`.**

   The stress process should be visible during the chaos window.

***

### Recovery and cleanup <a href="#recovery-and-cleanup" id="recovery-and-cleanup"></a>

* **End of duration:** The chaos pod stops the stress workload through Guest Operations.
* **Abort the experiment:** Stopping the experiment from Chaos Studio also stops the workload.
* **Manual recovery:** SSH into the VM and `sudo pkill -f stress-ng` if the workload survived.

***

### Limitations <a href="#limitations" id="limitations"></a>

* **VMware Tools required:** Without VMware Tools, vCenter cannot inject the workload.
* **Guest user privileges:** If `VM_USER_NAME` cannot run the stress binary, the fault errors out.
* **Single VM per run:** Each fault run targets one `VM_NAME`. Use multiple experiments to fan out.
* **ESXi co-tenant impact:** Aggressive `CPU_LOAD` on `CPU_CORES` close to the VM's vCPU count can affect co-tenants; size conservatively in production.

***

### Troubleshooting <a href="#troubleshooting" id="troubleshooting"></a>

<details>

<summary>VMware CPU hog fails with VMware Tools not running in Harness Chaos Engineering</summary>

The Guest Operations API requires VMware Tools to be installed and running on the target VM. Install or restart open-vm-tools / VMware Tools on the guest and retry.

</details>

<details>

<summary>VMware CPU hog fails with authentication failure</summary>

Verify GOVC\_URL, GOVC\_USERNAME, GOVC\_PASSWORD against vCenter and VM\_USER\_NAME / VM\_PASSWORD against the guest. For self-signed vCenter certificates, set GOVC\_INSECURE=true.

</details>

<details>

<summary>No CPU spike visible after starting the fault</summary>

Confirm the stress binary is installed inside the guest. SSH into the VM and run which stress-ng. Reinstall it per the VMware Linux binary installation page if missing.

</details>

***

### Related faults <a href="#related-faults" id="related-faults"></a>

* [VMware memory hog](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-memory-hog.md): Stress memory instead of CPU.
* [VMware IO stress](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-io-stress.md): Stress disk IO instead of CPU.
* [VMware VM power off](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/vcenter/vmware-vm-poweroff.md): Power off the VM entirely.