Fix Azure Operator Nexus Storage Appliance Issues

One of the most common sources of confusion in Azure Operator Nexus environments, especially after a second storage appliance is added, is not knowing which physical appliance maps to which Azure resource. The rule is straightforward once you know it, but Microsoft doesn't surface it prominently in the portal.

The aggregator rack in every Azure Operator Nexus instance has two dedicated rack slots for storage appliances. Rack slot 1 always holds the first storage appliance. If your deployment includes a second storage appliance, it occupies rack slot 2. There is no ambiguity here, this is a physical assignment enforced by the hardware design.

To view your storage appliance details including capacity and status, run:

az networkcloud storageappliance show \
  --name <STORAGE_APPLIANCE_NAME> \
  --resource-group <YOUR_RESOURCE_GROUP> \
  --subscription <SUBSCRIPTION_ID>

The output will include the rackId and slot information that maps the Azure resource back to the physical hardware. Cross-reference this against your physical rack documentation to confirm which unit you're looking at.

If you're evaluating whether you need a second storage appliance, check your BOM version first. A second appliance is only supported on instances running BOM version 2.0.x or later, and all Pure storage appliances in the instance must have R4 controllers. Attempting to add a second appliance on older hardware will fail at validation. Run the following to check your cluster's BOM version:

az networkcloud cluster show \
  --name <CLUSTER_NAME> \
  --resource-group <YOUR_RESOURCE_GROUP> \
  --query "clusterVersion" \
  --output tsv

If the command returns the storage appliance with status Available and provisioningState Succeeded, you've confirmed the appliance is healthy and correctly identified. Move to step 2.

When your Azure Operator Nexus storage appliance lands in Error status, the first instinct is to try recreating or deleting the resource. Don't. The platform actively blocks those operations, storage appliances are created and deleted only through internal cluster lifecycle management. Attempting to force it will just produce another error.

Instead, your path forward is to gather the right diagnostic data and either resolve the underlying cluster issue or escalate with the right information. Here's how to get that data.

First, check the cluster's overall health. The storage appliance status is downstream of the cluster state:

az networkcloud cluster show \
  --name <CLUSTER_NAME> \
  --resource-group <YOUR_RESOURCE_GROUP> \
  --query "{status:detailedStatus, message:detailedStatusMessage}" \
  --output json

If the cluster itself shows a Failed or degraded state, that's almost certainly what's driving the storage appliance error. The cluster's Hardware Validation phase checks every machine's hardware health before deployment proceeds, if that phase detected issues with BIOS boot settings or other hardware components, those need to be resolved first.

Next, pull the activity log for the storage appliance resource to see what operations were attempted and when:

az monitor activity-log list \
  --resource-id <STORAGE_APPLIANCE_RESOURCE_ID> \
  --start-time 2026-04-14T00:00:00Z \
  --output table

Look for failed operations and their error codes. The most actionable errors will have a clear message, things like hardware validation failures, network fabric connectivity issues, or internal provisioning timeouts. If you see internal errors with no clear message, that's typically a signal to escalate to Microsoft support with the full activity log output.

Once the underlying issue is resolved, usually through a cluster repair or redeployment operation, the storage appliance status should transition back to Available on its own within a few minutes.

PVC provisioning failures on Azure Operator Nexus storage are almost always one of three things: wrong size, wrong storage class, or wrong access mode. Let me break each one down.

Wrong size for nexus-volume: If you request less than 1 MiB or more than 12 TiB, the provisioning request fails outright. Check your PVC spec:

kubectl get pvc <PVC_NAME> -n <NAMESPACE> -o yaml | grep -A5 resources

Fix the size in your manifest and reapply. Example of a valid nexus-volume PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-rwo-volume
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi
  storageClassName: nexus-volume

nexus-shared capacity trap: You can provision a nexus-shared PVC requesting more than 1 TiB, the API won't reject it. But the backing NFS server has a hard limit of 1 TiB. Your pod will eventually hit an out-of-disk-space error. Keep all nexus-shared PVC requests at or below 1 TiB, and track total consumption across all nexus-shared PVCs because the 1 TiB limit is shared across all of them.

CSI ephemeral volumes: Azure Operator Nexus does not support CSI ephemeral volumes at all. If your workload manifest uses csi inline volume definitions instead of PVCs, you'll get a scheduling failure. Convert these to PVC-backed volumes before deploying.

After correcting your manifest, apply it and immediately watch PVC status:

kubectl get pvc -w -n <NAMESPACE>

You should see the status transition from Pending to Bound within 30–60 seconds if the fix was correct.

ReadWriteMany (RWX) workloads on Azure Operator Nexus use the nexus-shared storage class, which is backed by an NFS server. These setups let multiple pods on different nodes read from and write to the same volume simultaneously, which is powerful, but also the source of some specific failure modes.

The most common issue I see: a deployment is configured for RWX but pods end up on the same node, which works but defeats the purpose, or, worse, pods fail to schedule because pod anti-affinity rules are misconfigured.

Here's the correct affinity configuration to ensure pods land on different nodes:

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: kubernetes.azure.com/agentpool
              operator: Exists
              values: []
        topologyKey: "kubernetes.io/hostname"

This tells the scheduler that no two pods from this deployment should land on the same node. If you have more replicas than available nodes, some pods will stay in Pending state, that's expected behavior, not a storage issue.

To verify that your RWX setup is actually sharing data correctly across pods, exec into two different pods and check that they see each other's writes:

kubectl exec <POD_1_NAME> -- cat /mnt/hostname.txt
kubectl exec <POD_2_NAME> -- cat /mnt/hostname.txt

Both commands should show identical content that includes writes from all pods. If one pod's output only shows its own writes, your PVC isn't actually in RWX mode, check that accessModes is set to ReadWriteMany and the storage class is nexus-shared, not nexus-volume.

Also remember: each pod in an RWX deployment shares the same single PVC. This is fundamentally different from a StatefulSet using nexus-volume (RWO), where each pod gets its own dedicated PVC. Mixing these up in your manifest is an easy mistake that results in confusing behavior.

Two operational tasks that get skipped more than they should: enabling remote vendor management and setting up storage capacity monitoring. Both are critical for long-term health of your Azure Operator Nexus storage appliance, and both are available through straightforward Azure CLI commands.

Enable Remote Vendor Management:

az networkcloud storageappliance enable-remote-vendor-management \
  --name <STORAGE_APPLIANCE_NAME> \
  --resource-group <YOUR_RESOURCE_GROUP>

This enables Microsoft and the hardware vendor (Pure Storage) to perform remote diagnostics and maintenance. Without it, any hardware-level issue requires an on-site visit to diagnose. Enable this from day one, you can always disable it later:

az networkcloud storageappliance disable-remote-vendor-management \
  --name <STORAGE_APPLIANCE_NAME> \
  --resource-group <YOUR_RESOURCE_GROUP>

Monitor Capacity: All physical volumes on Azure Operator Nexus are thin-provisioned. This means the storage appliance doesn't actually reserve the storage you request, it allocates space as data is written. The risk is overcommitment: you can provision a set of PVCs whose total requested capacity exceeds physical capacity, and everything works fine until writes start hitting the actual limit.

You must monitor both the storage appliance's total consumption and all NFS servers (for nexus-shared volumes) using the platform metrics. Set up alerts on storage consumption percentage, I'd recommend alerting at 70% and paging at 85%. Hitting 100% causes out-of-disk-space errors on all workloads consuming affected volumes, and those errors can be disruptive and sudden.

To check current capacity from the CLI:

az networkcloud storageappliance show \
  --name <STORAGE_APPLIANCE_NAME> \
  --resource-group <YOUR_RESOURCE_GROUP> \
  --query "capacity" \
  --output json

The output will show both total and used capacity. Build this check into your regular operational runbook.