Request for procedure to add a standalone NVMe/SSD (7.68 TB) to an Azure Local node without claiming it into Storage Spaces Direct (S2D)

Question

Request for procedure to add a standalone NVMe/SSD (7.68 TB) to an Azure Local node without claiming it into Storage Spaces Direct (S2D)

kartik Sarsawat 20

Issue / Request Summary:

We need the supported end-to-end documentation and technical procedure to install and configure an additional 7.68 TB drive on a single node within an existing Azure Local (Azure Stack HCI) cluster.

Key Requirement:

This drive must remain standalone on that specific node and must NOT be claimed or automatically pooled into Storage Spaces Direct (S2D). It will be used for dedicated local storage (e.g., local backup staging / temporary landing zone) rather than shared cluster storage.

Environment Details:

Platform: Azure Local / Azure Stack HCI

OS Version: OS Version, 23H2
Cluster Name: XXXXXXXXX
Target Node: NODE1
Drive Type / Model: 7.68 TB [NVMe]

Information & Steps Requested:

What is the recommended method to prevent S2D from automatically claiming the newly inserted physical disk into the storage pool?

Guidance on setting CanPool flags, configuring BusType rules, or marking the disk as Allocated / IsManualAttach.

Specific PowerShell commands to safely verify and initialize the disk locally (e.g., partitioning, formatting ReFS/NTFS, assigning mount points or drive letters) without triggering S2D rebalance or validation warnings.

Does having an asymmetric physical disk configuration across nodes cause health service or Cluster Validation / Solution Update check warnings, and how can those alerts be suppressed or handled properly?

0 comments

1 answer

Your answer

Answer 1

Hello @kartik Sarsawat

There is no documented, supported per-disk exclusion mechanism for keeping an otherwise eligible NVMe drive outside Storage Spaces Direct on an Azure Local 23H2 node.

CanPool is the reported disk eligibility state; it is not a flag to assign manually.

BusType describes how Windows detects the device. Changing or falsifying it is not a supported exclusion method.

Set-PhysicalDisk -Usage ManualSelect, Retired, or similar values apply to a disk already associated with a storage pool; they do not provide a documented pre-claim exclusion mechanism for an unpooled disk.

Azure Local exposes the cluster-wide Health Service setting System.Storage.PhysicalDisk.AutoPool.Enabled. Its current value can be checked with:

Get-StorageSubsystem Cluster* |
    Get-StorageHealthSetting |
    Select-Object "System.Storage.PhysicalDisk.AutoPool.Enabled"

Disabling AutoPool only is a cluster-wide behavior. When disabled, replacement or newly added eligible drives are not automatically added to the S2D pool; Microsoft’s documented replacement procedure then requires manual disk addition. It is not a per-disk control.

I therefore do not recommend disabling AutoPool and initializing this NVMe locally without written confirmation from Microsoft Support and the Azure Local hardware vendor. Azure Local hardware validation checks that cluster machines are configured uniformly, and the vendor’s Solution Builder Extension can add hardware-specific validation during update and lifecycle operations. An additional disk on only one node can consequently cause validation or vendor-supportability findings, depending on the certified solution.

I cannot find verified official documentation to support a definitive, supported end-to-end procedure for using an eligible internal NVMe as standalone node-local storage in this specific Azure Local 23H2 configuration. Before inserting or initializing the disk, open a Microsoft support request and obtain confirmation from the server vendor that:

The certified hardware configuration permits the additional drive.
A node-asymmetric disk layout will not block lifecycle-management or Solution Builder Extension validation.
Disabling AutoPool, even temporarily, is supported for this intended use.
The vendor has a supported mechanism for exposing this device to the OS without presenting it as S2D-eligible storage.

Without that confirmation, the supported design is to keep Azure Local data drives under S2D management and place the backup staging or landing zone on storage external to the Azure Local data-drive set.

References:

Replace failed drives on Azure Local

Modify Health Service settings

Azure Local Environment Checker

Solution Builder Extension updates

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.