Azure Local s2d Infrastructure_1 storage job sitting at suspended

Leon CHol 20 Reputation points
2026-08-18T14:42:21.8366667+00:00

After a pause, drain, and reboot of one azure local node, the infrastructure_1 repair job is stuck on suspended for 16 hours.

After a planned maintenance reboot of a node, all user-facing virtual disks recovered to Healthy/OK status. The only remaining unhealthy object is Infrastructure_1 (252 GB mirror virtual disk), which remains in Warning/InService state. VirtualDisk.Repair health actions continue to be scheduled at 0% and associated Infrastructure_1-Repair jobs remain suspended with 0 bytes processed. No physical disk, storage pool, CSV, fault domain, or ClusterPerformanceHistory issues are present.

according to Copilot.

The outstanding issue appears to be a stuck S2D/Azure Local Infrastructure_1 repair orchestration state rather than an actual storage failure.

suggestions?

Copilot suggested I not manually migrate the vms, and reboot.

Azure Local
0 comments
Answer accepted by question author
Jose Benjamin Solis Nolasco 12,036 Reputation points Volunteer Moderator
2026-08-18T14:55:53.5066667+00:00

Welcome to Microsoft Q&A!

Hello @Leon CHol

Microsoft's Storage Spaces Direct guidance notes that a repair job can temporarily enter Suspended and later resume. The important part is to determine whether the job is actually making progress or whether it has remained indefinitely at 0% / 0 bytes. (learn.microsoft.com)

Since your physical disks, pool, CSVs, and fault domains are healthy and the user-facing virtual disks have recovered, I would avoid manually migrating VMs or making changes to the Infrastructure_1 virtual disk at this stage.

What I would check first

From an elevated PowerShell session, capture:

Get-StorageJob   Get-VirtualDisk -FriendlyName "Infrastructure_1" |     Format-List FriendlyName,OperationalStatus,HealthStatus,HealthStatusReason,DetachedReason   Get-VirtualDisk -FriendlyName "Infrastructure_1" |     Get-PhysicalDisk |     Format-Table FriendlyName,OperationalStatus,HealthStatus,Usage,Size   Get-StoragePool |     Format-Table FriendlyName,OperationalStatus,HealthStatus,IsReadOnly

Also check whether the job's BytesProcessed or PercentComplete changes over time. Microsoft recommends Get-StorageJob specifically for monitoring S2D repair operations. (learn.microsoft.com)

About rebooting

I would not perform repeated reboots solely to try to clear the suspended job. You already performed a planned maintenance reboot and the VM-facing disks recovered, so another reboot may not address the underlying storage orchestration state.

If the repair remains at Suspended / 0% / 0 bytes with no change for an extended period, the next step should be to investigate the S2D/Azure Local storage state rather than manually deleting or resetting the repair job.

Azure Local also provides Repair-ClusterStorageSpacesDirect for repairing S2D disks, but I would not run a cluster-wide repair command blindly while the cluster is otherwise healthy. First collect the health/job output and confirm the exact condition requiring repair. (learn.microsoft.com)

If you can provide the output of Get-StorageJob and Get-VirtualDisk -FriendlyName "Infrastructure_1", particularly OperationalStatus, HealthStatus, and HealthStatusReason, it should be possible to determine whether this is a normal suspended repair waiting for a condition or a repair that is genuinely stuck.

References:

If this answer helped clarify the platform capabilities and save you troubleshooting time, please consider marking it as Accepted. This helps others in the community find similar solutions.

 

Was this answer helpful?

1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Leon CHol 20 Reputation points
    2026-08-18T15:45:10.6233333+00:00

    Single reboot after forcedrain fixed my issue.

    but used with caution. after working with copilot.

    Was this answer helpful?

  2. AI answer

    2026-08-18T14:42:39.68+00:00

    Based on the described state, the next checks are to confirm whether this is a lingering repair orchestration state and whether a crash-recovery scan is still required.

    1. Check for active storage repair progress: 
         Get-StorageJob
      If the repair remains suspended and does not advance, that matches the documented pattern where repair can suspend and later resume, but it must eventually complete.
    2. Check the virtual disk state directly: 
         Get-VirtualDisk
      Verify whether Infrastructure_1 still shows Warning / InService instead of returning to Healthy.
    3. Check whether the crash-recovery integrity scan is still running: 
         Get-ScheduledTask | ? State -eq running
      The documented Data Integrity Scan for Crash Recovery does not appear as a storage job and has no progress indicator. If it is running, it is still working. If it completes, the virtual disks should return to healthy state.
    4. If the issue started after the node reboot and the repair remains suspended with no byte progress, avoid interrupting any running crash-recovery scan. If that task is canceled or a node is restarted while it is running, it must start over from the beginning.
    5. If Infrastructure_1 remains stuck after confirming there is no active crash-recovery task and no storage job progress, collect cluster diagnostics and review the cluster state around the failed maintenance sequence. The available guidance for Azure Local maintenance is to suspend the node with drain before maintenance and confirm node state with: 
         Get-ClusterNode

    The available documentation does not provide a supported manual repair/reset procedure specifically for a stuck Infrastructure_1 repair orchestration state when user-facing disks are already healthy. It only documents monitoring repair jobs, checking for the crash-recovery scheduled task, and avoiding interruption of that task.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.