+
+ | Name |
+ AzStackHci_Hardware_Test_SystemDrive_Free_Space |
+
+
+ | Telemetry / health-scanner name |
+ AzStackHci_Hardware_SystemDriveFreeSpace (same check; this is the name used in Azure telemetry and the health-fault scanner) |
+
+
+ | Display name |
+ Test System Drive Free Space |
+
+
+ | Component |
+ Hardware (Environment Validator / Environment Checker) |
+
+
+ | Severity |
+ Critical: this validator blocks deployment and update operations until the machine is back above the minimum. |
+
+
+ | Required free space |
+ 30 GB on the system drive (C:) of every machine. |
+
+
+ | Applicable Scenarios |
+ Deployment, Add Node, and Update / Upgrade (pre-update health check). |
+
+
+ | Affected Versions |
+ Azure Local, version 23H2 and later. |
+
+
+
+## Overview
+
+This validator checks that the system drive (the `C:` drive) on each Azure Local
+machine has enough free space for the platform to operate and to install updates.
+It fails when free space on `C:` drops below the required minimum of **30 GB** on
+any machine in the cluster.
+
+A low system drive is a real problem, not just a warning. While the check is
+failing:
+
+- Solution (Azure Local) updates and upgrades are blocked at pre-update
+ validation, so the cluster cannot be patched.
+- Adding a machine to the cluster can fail validation.
+- New Arc and Kubernetes extensions may fail to deploy.
+- Existing workloads keep running, but the machine cannot be lifecycle-managed
+ reliably, and a drive that fills to zero can destabilize the node.
+
+## Where this failure appears
+
+You can see this failure in two places, the Azure portal and the machine itself.
+Both show the same underlying result.
+
+### In the Azure portal
+
+The check runs as part of the update readiness and system health checks, so it
+shows up in Azure Update Manager:
+
+1. Go to **Azure Update Manager > Resources > Azure Local**, or open the **Azure
+ Local** resource and its **Updates** page.
+2. In the system list, select the **Update readiness** status. A system that needs
+ attention shows a **Critical** or **Warning** state.
+3. Review the list of readiness checks. On current builds this appears as **System
+ Drive Free Space** (earlier builds: **Test System Drive Free Space**).
+4. Select the link under **Details**. The details pane shows the per-machine
+ results and a **Remediation** link (`https://aka.ms/hci-envch`).
+
+The portal does not show the raw JSON shown below. It renders the same result as a
+row in the readiness check list, with the display name, the Critical severity, the
+affected machine, and the remediation link.
+
+This check is reported in two scenarios, and the results can differ between them
+because each uses a different version of the validation logic:
+
+- **System health checks**, which run once every 24 hours.
+- **Update readiness checks**, which run after the update content is downloaded
+ and before installation.
+
+### On the machine
+
+Two on-box sources carry the result.
+
+**Event log (per machine).** The Environment Checker writes every check result to
+the **AzStackHciEnvironmentChecker** event log, located at
+`C:\Windows\System32\winevt\Logs\AzStackHciEnvironmentChecker.evtx`. Each result is
+the JSON body of an **Event ID 17205** entry. To read this check's most recent
+result on a machine:
+
+```powershell
+Get-WinEvent -LogName AzStackHciEnvironmentChecker -FilterXPath '*[System[(EventID=17205)]]' -MaxEvents 2000 |
+ Where-Object { $_.Message -match 'AzStackHci_Hardware_(Test_SystemDrive_Free_Space|SystemDriveFreeSpace)' } |
+ Select-Object -First 1 -ExpandProperty Message
+```
+
+**Pre-update health check result file (cluster-wide).** The pre-update health
+check writes its full result set to the cluster infrastructure share:
+
+```
+C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\Updates\HealthCheck\System\HealthCheckResult.EnvironmentChecker.