Skip to content

Add Storage TSG: physical disks stuck in verification (CanPool=False) due to a wedged Health Service#333

Open
1008covingtonlane wants to merge 3 commits into
Azure:mainfrom
1008covingtonlane:tsg-storage-physicaldisk-verification-stuck
Open

Add Storage TSG: physical disks stuck in verification (CanPool=False) due to a wedged Health Service#333
1008covingtonlane wants to merge 3 commits into
Azure:mainfrom
1008covingtonlane:tsg-storage-physicaldisk-verification-stuck

Conversation

@1008covingtonlane

Copy link
Copy Markdown
Collaborator

What

Adds a focused Storage TSG for the scenario where new, clean, vendor-supported disks stay CanPool=False with CannotPoolReason = Verification in progress that never clears, because the cluster Health Service (the Health resource in the SDDC Group) is wedged and its supportability verification never completes. The tell is that the same disk pools normally in a different, healthy cluster.

This is a companion to the existing Troubleshoot-Storage-PhysicalDiskCanPoolFalse.md, which covers the general CannotPoolReason decision tree. That guide's Verification in progress step is "wait and recheck"; this guide picks up where that stalls forever, and adds the Health-Service deep-dive.

Contents

  • Discover: symptoms, an at-a-glance box (impact / owner / downtime / fastest step), and an 8-surface admin discoverability table.
  • Debug: confirm the disk is stuck in verification, confirm the block is cluster-side (not disk / node / slot / HBA / asymmetric-add / provider-cache), inspect the Health Service and its Providers cluster parameter vs a healthy same-build peer.
  • Mitigate (least-risk first): Step A reinitialize the Health Service (fail the SDDC Group over; single-node uses Stop/Start-ClusterResource); Step B (support-assisted, gated) restore the Providers list from a healthy same-build peer with a backup, hard-stops, and round-trip verification; Step C claim the eligible disks and rebalance.
  • Glossary, prevention, data-to-collect, and escalation.

Validation

Built and graded with an internal tsg-forge harness. The Health Service provider-config remediation loop (Step A + Step B) was validated end-to-end on a lab S2D cluster: baseline healthy providers, injected an incomplete set, detected it, restored + failed the group over, revalidated. Report card: Grade A, 5/5 usability panel across 13 reader personas, 8/8 admin discoverability surfaces. The downstream CanPool chain is described from the source support case and the Microsoft Learn CannotPoolReason / verification model.

No PII: all cluster names, serials, and provider GUIDs are placeholders.

… due to a wedged Health Service

New disks can stay CanPool=False with CannotPoolReason 'Verification in
progress' that never clears because the cluster Health Service (the Health
resource in the SDDC Group) is wedged and its supportability verification
never completes. The same disk pools fine in a healthy cluster.

This is a focused companion to Troubleshoot-Storage-PhysicalDiskCanPoolFalse.md
(which covers the general CannotPoolReason decision tree). It adds the
Health-Service deep-dive: confirm the block is cluster-side, inspect the Health
Service and its Providers parameter, then remediate least-risk-first (Step A:
fail the Health group over; Step B, support-assisted: restore the Providers
list vs a healthy same-build peer), then claim and rebalance the disks.

Covers discover -> debug -> mitigate with an at-a-glance box, an 8-surface
admin discoverability table, safety gates on every state-changing step, and a
glossary.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4fd8e523-73e9-4f9c-851a-7c5c1a8b08a0
Copilot AI review requested due to automatic review settings July 15, 2026 17:14

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a focused Storage TSG for disks stuck in Health Service verification.

Changes:

  • Adds diagnosis and remediation procedures.
  • Includes guarded provider restoration and disk pooling steps.
  • Adds the guide to the Storage index.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File Description
TSG/Storage/Troubleshoot-Storage-PhysicalDiskVerificationStuck.md Adds the troubleshooting guide.
TSG/Storage/README.md Links the new guide.

Comment thread TSG/Storage/Troubleshoot-Storage-PhysicalDiskVerificationStuck.md Outdated
Comment thread TSG/Storage/Troubleshoot-Storage-PhysicalDiskVerificationStuck.md Outdated
Comment thread TSG/Storage/Troubleshoot-Storage-PhysicalDiskVerificationStuck.md Outdated
Comment thread TSG/Storage/Troubleshoot-Storage-PhysicalDiskVerificationStuck.md Outdated
Comment thread TSG/Storage/Troubleshoot-Storage-PhysicalDiskVerificationStuck.md Outdated
1008covingtonlane and others added 2 commits July 15, 2026 13:37
Fixes from the Copilot PR review on Azure#333:
- Step 2: do not recommend moving a disk into another PRODUCTION cluster as a
  diagnostic (a clean disk can be auto-claimed there); frame as already-observed
  evidence or use a spare/non-production cluster.
- Step B backup: create C:\Temp and stop on backup failure before continuing,
  so the internal-parameter edit never proceeds without a verified rollback copy.
- Step B completeness gate: prove completeness against an independently recorded
  peer count (not "larger than the broken set"), reject placeholders, and require
  every entry to be a unique GUID before writing.
- Step B reinitialize: re-run Step A's full guarded failover procedure instead of
  a duplicated, weaker block that omitted the node/storage-job gates.
- Step C: validate each intended serial matches exactly one eligible disk (per
  serial, not in aggregate) and reject duplicate serials.

Lint A; all rewritten PowerShell blocks parse clean.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4fd8e523-73e9-4f9c-851a-7c5c1a8b08a0
Merge the pre-move inspection/gate and the failover blocks into a single
continuous block so the variables it derives ($hs, $upNodes, $originalOwner)
are always in scope, and it is copy-paste-robust if run on its own. The gate
is now enforced in code (throws if a node is down or a storage job is running)
instead of relying on the operator reading the previous block's output.

Addresses the review note on out-of-order execution. Lint A; block parses clean.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 4fd8e523-73e9-4f9c-851a-7c5c1a8b08a0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants