Can an external iSCSI storage array be attached to an already deployed Azure Local cluster?

Question

Can an external iSCSI storage array be attached to an already deployed Azure Local cluster?

Mishra, Keshav Kumar (PSD-GCC) 80

Hello! I am looking for clarification on external iSCSI storage support in Azure Local.

Can an external iSCSI storage array be connected to an Azure Local cluster after the cluster has already been deployed, or must it be configured during the initial deployment process?

Specifically, I would like to understand:

Is post-deployment attachment of an external iSCSI storage array supported?
If supported, are there any prerequisites or limitations?

Nikhil Duserla 9,950 Reputation points Microsoft External Staff Moderator

2026-07-08T16:20:22.9166667+00:00
Hey! Good question—this is one of those areas where Azure Local external SAN integration is definitely doable, but it’s important to separate “supported” from “how it’s done operationally.”

Based on the provided documentation, external iSCSI SAN arrays are supported by Azure Local when you connect them using the documented external storage procedure (iSCSI connectivity, verification, and CSV presentation). The docs describe the integration as a host-side + array-side workflow, including iSCSI target portal discovery/connection and validation from every Azure Local node, then initializing/formatting SAN volumes so the cluster can manage them as CSVs (NTFS).

Is post-deployment attachment supported?

The provided docs do not explicitly state “yes/no, you can attach iSCSI storage after cluster deployment” in a single sentence.

However, the “Connect an external storage array to Azure Local” content is written as an integration process that applies to Azure Local clusters (FC/iSCSI external storage alongside S2D, or SAN-only). It describes the steps to connect iSCSI targets and then verify and bring the LUNs into the cluster as CSVs—meaning the intended scenario is that you can integrate external SAN storage into an already deployed Azure Local cluster by following the procedure.

So, while the documentation doesn’t explicitly answer “post-deployment” as a standalone policy statement, it does describe the mechanics needed to perform the integration after the cluster exists, including prerequisites and multi-node requirements.

Prerequisites / limitations called out for iSCSI

From the provided iSCSI external storage prerequisites:

Azure Local cluster version must be 2604 or later.

NIC firmware and driver versions must match the Azure Local hardware catalog requirements.

All nodes must use identical NIC configurations.

Hybrid storage (Storage Spaces Direct + iSCSI) requires dedicated physical ports for iSCSI (vNICs aren’t supported).

iSCSI integration is currently in preview (per the provided “Supported protocols” section).

What you should expect to do (high level)

For iSCSI, the docs call out that you:

Prepare the SAN side: create/map LUNs to all cluster nodes, create host entries using initiator IDs, and provide target portal IPs + target IQNs (and ensure each node can reach each target portal on port 3260).

On every Azure Local node:

Discover target portals from both iSCSI NICs

Connect using persistence + multipath enabled (via New-IscsiTargetPortal and Connect-IscsiTarget)

Verify and reboot nodes (rolling restart) to apply MPIO changes

Verify SAN disks across nodes (compare UniqueId)

Initialize/format SAN volumes on a single node (GPT + NTFS, CSV settings), then the cluster manages access via CSVs.

Follow-up questions (so we can tailor the answer to your exact scenario)

What Azure Local version is your deployed cluster running (confirm >= 2604)?

Are you planning SAN-only (disaggregated) or hybrid (S2D + iSCSI)?

Are you using preview iSCSI external storage in your environment, or do you need GA-only guidance?

Do you intend to connect new LUNs or already-existing SAN LUNs?

Are you able to ensure identical iSCSI NIC configurations on all nodes and dedicated physical iSCSI ports (for hybrid)?

If you share those details, we can help craft a precise public-forum response that matches the deployment type and highlights the relevant prerequisites.

References (from the provided documentation)

Connect an external storage array to Azure Local (iSCSI steps included)

External storage support for Azure Local (concepts/overview)

Azure Local Storage Architecture (Storage Spaces Direct + SAN) / prerequisites (FC and iSCSI)

Troubleshoot Detached Storage Spaces Direct (not directly about iSCSI attach, but included in provided materials)

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Yes — an external iSCSI array can be integrated with an already deployed Azure Local cluster. It is not an initial-deployment-only option, so a redeployment is not required. The important qualification is that iSCSI external SAN support is currently preview, while Fibre Channel external SAN support is generally available. If your organization requires GA-only features, use FC or confirm preview use with your support and change-control teams.

For a deployed cluster, I would treat this as a planned storage onboarding change:

Validate the supported configuration first. The cluster must be on Azure Local 2604 or later. NIC firmware/drivers must meet the Azure Local hardware catalog, and every node needs the same iSCSI NIC configuration. In an S2D + iSCSI hybrid design, iSCSI requires dedicated physical ports; do not use vNICs or place those NICs in a Network ATC intent.
Prepare the SAN consistently. Create new LUNs and present every LUN to every cluster node using each node’s iSCSI IQN. Use the same LUN identity across all nodes, provide redundant target portals, and verify each node can reach TCP 3260. Confirm with the array vendor that the LUNs support SCSI-3 persistent reservations.
Configure hosts before clustering the disks. Enable/verify MPIO and start the Microsoft iSCSI Initiator service on every node. Connect to each target from both iSCSI NICs with persistence and multipath enabled. The iSCSI subnets should use static addressing and no default gateway.
Validate before writing anything. On every node, rescan and compare the LUN UniqueId values (disk numbers can differ). Run Test-Cluster -Include Storage. Do not initialize or format a LUN containing existing data unless its recovery/ownership plan has been confirmed.
Bring it into Azure Local. For new empty LUNs, initialize and format on one node (GPT + NTFS; Microsoft recommends 64K allocation for a CSV), add the disk to the cluster, convert it to a CSV, then register its C:\ClusterStorage\... path as an Azure Local storage path for VM placement.

The official runbook is here: Connect an external storage array to Azure Local. The external storage support overview also calls out the iSCSI preview status and supported deployment models.

Before starting, I would capture the Azure Local version, array model/firmware, and whether this is SAN-only or S2D + SAN. Those three details determine whether the iSCSI design is in supported scope.

Can an external iSCSI storage array be attached to an already deployed Azure Local cluster?

Is post-deployment attachment supported?

Prerequisites / limitations called out for iSCSI

What you should expect to do (high level)

Follow-up questions (so we can tailor the answer to your exact scenario)

References (from the provided documentation)

0 additional answers

Your answer