> 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/azure/azure-disk-loss.md).

# Azure disk loss

Azure disk loss is an Azure chaos fault that detaches one or more managed data disks listed in `VIRTUAL_DISK_NAMES` from their attached VMs (in `RESOURCE_GROUP`, subscription `AZURE_SUBSCRIPTION_ID`) for `TOTAL_CHAOS_DURATION` seconds, then reattaches them on the same LUN. OS disks are excluded by design.

Use this fault to test how a workload behaves when its storage disappears: whether the application surfaces clean IO errors, whether file systems remount cleanly when the disk returns, whether backup and DR strategies cover sudden volume loss, and whether monitoring detects the volume loss 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:

* **Storage loss handling:** When the data disk disappears, does the application surface a clean error or wedge on IO?
* **Filesystem recovery:** Does the filesystem remount cleanly when the disk is reattached?
* **Stateful workload resilience:** Do databases (Postgres, MySQL, Cassandra) recover from a brief storage outage?
* **Monitoring fidelity:** Do alerts on `Microsoft.Compute/disks/Availability` and application errors fire within the alerting SLA?

***

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

* **Kubernetes version:** 1.21 or later for the chaos infrastructure cluster.
* **Disks are data disks:** Every entry in `VIRTUAL_DISK_NAMES` is a managed data disk currently attached to a VM in `RESOURCE_GROUP`. OS disks are rejected.
* **Azure credentials available:** Service principal File Secret, workload identity, or managed identity on the AKS node pool.
* **RBAC granted:** The principal includes the role listed below.

***

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

| Platform                               | Support status                     |
| -------------------------------------- | ---------------------------------- |
| Standalone VMs with managed data disks | Supported                          |
| VMSS instances with managed data disks | Supported (set `SCALE_SET=enable`) |
| Ultra Disk and Premium SSD v2          | Supported (subject to LUN limits)  |
| OS disks                               | Not supported                      |

***

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

The Azure principal used by the chaos pod needs the following role on the target resource group or subscription.

**Recommended built-in role:** `Virtual Machine Contributor`

**Custom role (minimum actions):**

```json
{
  "Name": "Harness Chaos Disk Loss",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Compute/virtualMachines/write",
    "Microsoft.Compute/disks/read",
    "Microsoft.Compute/disks/write",
    "Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read",
    "Microsoft.Compute/virtualMachineScaleSets/virtualMachines/write"
  ],
  "AssignableScopes": ["/subscriptions/<SUBSCRIPTION_ID>"]
}
```

Go to [Azure fault permissions](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/security-configurations/fault-permissions.md) to read the full permission catalog.

***

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

Go to [Azure authentication methods](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/security-configurations/azure-authentication-methods.md) to set up Service principal, Workload identity, or Managed identity.

***

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

Configure the following fault parameters when you add Azure disk loss to an experiment in Chaos Studio. Defaults are shown for reference.

**Required parameters**

| Tunable              | Description                                      | Default    |
| -------------------- | ------------------------------------------------ | ---------- |
| `VIRTUAL_DISK_NAMES` | Comma-separated list of managed data disk names. | (required) |
| `RESOURCE_GROUP`     | Resource group that contains the disks.          | (required) |

**Chaos parameters**

| Tunable                | Description                                                                                                                                                                                                      | Default    |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TOTAL_CHAOS_DURATION` | Total duration of the fault in seconds. The disks stay detached for this period.                                                                                                                                 | `30`       |
| `CHAOS_INTERVAL`       | Delay in seconds between successive iterations when running for more than one cycle.                                                                                                                             | `30`       |
| `SCALE_SET`            | Set to `enable` when the disks are attached to VMSS instances.                                                                                                                                                   | `""`       |
| `SEQUENCE`             | Order in which multiple disks are detached: `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`        |

**Authentication**

| Tunable                       | Description                                                                                           | Default |
| ----------------------------- | ----------------------------------------------------------------------------------------------------- | ------- |
| `AZURE_SUBSCRIPTION_ID`       | Target Azure subscription ID.                                                                         | `""`    |
| `AZURE_CLIENT_ID`             | Client ID of a user-assigned managed identity.                                                        | `""`    |
| `AZURE_AUTHENTICATION_SECRET` | Identifier of the **File Secret in Harness Secret Manager** that contains the service principal JSON. | `""`    |

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>

Reads the current attachment for each disk in `VIRTUAL_DISK_NAMES` (the VM name and LUN), updates the VM to detach the disk, waits for `TOTAL_CHAOS_DURATION`, then updates the VM again to reattach the disk on the same LUN.

***

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

* Each affected VM loses the data disk for the duration; the OS block device disappears.
* Filesystems mounted from the detached disk go into an IO error state; processes accessing them block or return `EIO` / `STATUS_DISK_OPERATION_FAILED`.
* Azure Monitor disk metrics drop to zero on the affected device.
* After the duration ends, the disk reattaches on the same LUN; depending on the workload, the filesystem may remount automatically.

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

The chaos pod reattaches each disk to its original VM on the same LUN. Whether the filesystem remounts automatically depends on the VM's fstab and the application's IO retry behavior.
{% endhint %}

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

* **Block device on the VM:** Use a [command probe](/resilience-testing/chaos-testing/probes/command-probe.md) that SSHs to the VM and runs `lsblk`.
* **Application errors:** Use a [Prometheus probe](/resilience-testing/chaos-engineering/use-chaos-engineering/probes/apm-probes.md) on the application's IO-error counter.

***

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

1. **Inspect disk attachment.**

   ```bash
   az disk show --resource-group <rg> --name <disk> \
     --query "{state:diskState,managedBy:managedBy}"
   ```

   `managedBy` should be empty during the chaos window.
2. **Inspect the VM's block devices.**

   ```bash
   az vm run-command invoke --resource-group <rg> --name <vm> \
     --command-id RunShellScript --scripts "lsblk"
   ```

***

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

* **End of duration:** The chaos pod reattaches each detached disk on the same LUN.
* **Abort the experiment:** Stopping the experiment from Chaos Studio also reattaches the disks.
* **Manual recovery:** Run `az vm disk attach --resource-group <rg> --vm-name <vm> --name <disk> --lun <lun>` for any disk that stayed detached (LUN is recorded in the chaos pod logs).

***

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

* **Data disks only:** OS disks are not supported.
* **LUN preservation:** The fault reattaches on the same LUN as it was detached from; if a different process attached another disk to that LUN in the meantime, the call fails.
* **Same-subscription targeting:** A single experiment targets one `AZURE_SUBSCRIPTION_ID`.

***

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

<details>

<summary>Azure disk loss fails with OS disk cannot be detached in Harness Chaos Engineering</summary>

VIRTUAL\_DISK\_NAMES contains an OS disk. The fault refuses to detach OS disks by design. Pass only data disk names; verify with az disk show --query 'osType' (empty means data disk).

</details>

<details>

<summary>Azure disk loss fails with AuthorizationFailed</summary>

The Azure principal is missing Microsoft.Compute/virtualMachines/write or Microsoft.Compute/disks/write. Assign Virtual Machine Contributor (or a custom role with the required actions) on the target resource group or subscription.

</details>

<details>

<summary>Disk reattached but filesystem did not remount</summary>

The filesystem may not auto-remount depending on fstab. SSH into the VM and run sudo mount -a or remount the specific device. For application-level recovery, restart the dependent service.

</details>

***

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

* [Azure instance IO stress](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-instance-io-stress.md): Stress disk IO instead of detaching the disk.
* [Azure instance stop](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-instance-stop.md): Stop the VM instead of detaching its disk.