Make review markups

pjw711 · pjw711 · commit afe16c102ef0 · 2025-03-21T10:44:16.000Z
diff --git a/articles/operator-nexus/concepts-nexus-availability.md b/articles/operator-nexus/concepts-nexus-availability.md
@@ -59,7 +59,7 @@ Go through the following steps to help plan an Operator Nexus deployment.
 
 6.  Operator Nexus supports between 1 and 8 racks per site inclusive, with each rack containing 4, 8, 12 or 16 servers. All racks must be identical in terms of number of servers. See [here](./reference-near-edge-compute.md) for specifics of the resource available for workloads. See the following diagram, and also [this article](./reference-limits-and-quotas.md) for other limits and quotas that might have an impact.
 
-7.  Operator Nexus supports one or two Pure storage appliances. Storage appliances typically reach high levels of availability and data durability; precise numbers vary per vendor and per product. Azure Operator Nexus has redundant connectivity to the storage appliances on the management and data networks. Storage appliances provide storage to workload NFs running as Kubernetes nodes. Workloads running as VMs can either use local storage from the server they're instantiated on, or persistent storage provided by the storage appliance. See [here](./concepts-storage-virtual-machine.md) for further information. Note that, while persistent storage enables migrations of stopped VMs to an alternative BMM when their host BMM is stopped, it does not provide resiliency to unexpected BMM hardware failures. Additionally, there is no support for automatic or manual migration of volumes between storage appliances, and both storage appliances are located in the aggregator rack. This means, from a storage appliance perspective, Nexus deployments with two storage appliances have the same availability characteristics as deployments with one storage appliance: a volume is only ever on one storage appliance.
+7.  Operator Nexus supports one or two Pure storage appliances. Storage appliances typically reach high levels of availability and data durability; precise numbers vary per vendor and per product. Azure Operator Nexus has redundant connectivity to the storage appliances on the management and data networks. Storage appliances provide storage to workload NFs running on Kubernetes. Workloads running as VMs can either use local storage from the server they're instantiated on, or persistent storage provided by the storage appliance. See [here](./concepts-storage-virtual-machine.md) for further information. Note that, while persistent storage enables migrations of stopped VMs to an alternative BMM when their host BMM is stopped, it does not provide resiliency to unexpected BMM hardware failures. Additionally, there is no support for automatic or manual migration of volumes between storage appliances, and both storage appliances are located in the aggregator rack. This means, from a storage appliance perspective, Nexus deployments with two storage appliances have the same availability characteristics as deployments with one storage appliance: a volume is only ever on one storage appliance.
 
 8.  Other factors to consider are the number of available physical sites, and any per-site limitations such as bandwidth or power.
 
diff --git a/articles/operator-nexus/concepts-storage-multiple-appliances.md b/articles/operator-nexus/concepts-storage-multiple-appliances.md
@@ -85,9 +85,11 @@ Azure Operator Nexus provides a shared filesystem storage solution for container
 
 You can create the shared storage service on either storage appliance when the CSN is created. All nexus-shared PVCs using that shared storage service consume storage from the storage appliance backing the shared service. The configuration applies to all nexus-shared PVCs using the shared storage service provided by the CSN. All nexus-shared PVCs using the same shared storage service use the same storage appliance.
 
+The `nexusSharedStorageApplianceName` Azure resource tag controls which storage appliance is used to back the shared storage service. See [Prerequisites for deploying tenant workloads](./quickstarts-tenant-workload-prerequisites.md#create-a-cloud-services-network) for instructions on creating the shared storage service on a specific storage appliance.
+
 If no storage appliance configuration is provided at CSN creation time, the shared storage service uses the first storage appliance. If the configuration is present but doesn't match a storage appliance then the CSN creation will fail.
 
-See [Prerequisites for deploying tenant workloads](./quickstarts-tenant-workload-prerequisites.md#create-a-cloud-services-network) for instructions on creating the shared storage service on a specific storage appliance.
+Subsequent updates to the `nexusSharedStorageApplianceName` Azure resource tag have no effect. There is no support for moving the shared filesystem storage solution between storage appliances after initial deployment.
 
 #### Nexus-shared limitations
 
diff --git a/articles/operator-nexus/howto-configure-cluster.md b/articles/operator-nexus/howto-configure-cluster.md
@@ -82,7 +82,7 @@ az networkcloud cluster create --name "$CLUSTER_NAME" --location "$LOCATION" \
   --rack-serial-number "$AGGR_RACK_SN" \
   --rack-location "$AGGR_RACK_LOCATION" \
   --bare-metal-machine-configuration-data "["$AGGR_RACK_BMM"]" \
-  --storage-appliance-configuration-data '[{"adminCredentials":{"password":"$SA1_PASS","username":"$SA_USER"},"rackSlot":1,"serialNumber":"$SA1_SN","storageApplianceName":"$SA1_NAME"},{"adminCredentials":{"password":"$SA2_PASS","username":"$SA_USER"},"rackSlot":1,"serialNumber":"$SA2_SN","storageApplianceName":"$SA2_NAME"}]' \
+  --storage-appliance-configuration-data '[{"adminCredentials":{"password":"$SA1_PASS","username":"$SA_USER"},"rackSlot":1,"serialNumber":"$SA1_SN","storageApplianceName":"$SA1_NAME"},{"adminCredentials":{"password":"$SA2_PASS","username":"$SA_USER"},"rackSlot":2,"serialNumber":"$SA2_SN","storageApplianceName":"$SA2_NAME"}]' \
   --compute-rack-definitions '[{"networkRackId": "$COMPX_RACK_RESOURCE_ID", "rackSkuId": "$COMPX_RACK_SKU", "rackSerialNumber": "$COMPX_RACK_SN", "rackLocation": "$COMPX_RACK_LOCATION", "storageApplianceConfigurationData": [], "bareMetalMachineConfigurationData":[{"bmcCredentials": {"password":"$COMPX_SVRY_BMC_PASS", "username":"$COMPX_SVRY_BMC_USER"}, "bmcMacAddress":"$COMPX_SVRY_BMC_MAC", "bootMacAddress":"$COMPX_SVRY_BOOT_MAC", "machineDetails":"$COMPX_SVRY_SERVER_DETAILS", "machineName":"$COMPX_SVRY_SERVER_NAME"}]}]'\
   --managed-resource-group-configuration name="$MRG_NAME" location="$MRG_LOCATION" \
   --network fabric-id "$NF_ID" \
diff --git a/articles/operator-nexus/howto-platform-prerequisites.md b/articles/operator-nexus/howto-platform-prerequisites.md
@@ -474,7 +474,7 @@ Interface:    net1, via: LLDP, RID: 1, Time: 0 day, 20:28:36
 ## Set up first storage array
 
 1. Operator needs to install the storage array hardware as specified by the BOM and rack elevation
-   within the Aggregation Rack. The hardware must go in the first storage appliance rack slot in the aggregator rack.
+   within the Aggregation Rack.
 2. Operator needs to provide the storage array Technician with information, in order for the storage
    array Technician to arrive on-site to configure the appliance.
 3. Required location-specific data that is shared with storage array technician:
@@ -538,7 +538,7 @@ Interface:    net1, via: LLDP, RID: 1, Time: 0 day, 20:28:36
 > This section is optional. You only need to execute it if you are deploying an Azure Operator Nexus instance with two storage appliances. For more information, including restrictions on supported hardware, see [Azure Operator Nexus multiple storage appliances](./concepts-storage-multiple-appliances.md).
 
 1. Operator needs to install the storage array hardware as specified by the BOM and rack elevation
-   within the Aggregation Rack. The hardware must go in the second storage appliance rack slot in the aggregator rack.
+   within the Aggregation Rack.
 2. Operator needs to provide the storage array Technician with information, in order for the storage
    array Technician to arrive on-site to configure the appliance.
 3. Required location-specific data that is shared with storage array technician:
diff --git a/articles/operator-nexus/troubleshoot-multiple-storage-appliances.md b/articles/operator-nexus/troubleshoot-multiple-storage-appliances.md
@@ -35,7 +35,7 @@ If any of the configurations was incorrect:
 
 ## Nexus-volume Persistent Volume Claim (PVC) on the wrong storage appliance
 
-PVCs using the nexus-volume storage class can select the storage appliance to use for backing storage using the `storageApplianceName` annotation. If this annotation isn't present, the PVC uses the first storage appliance. You can check this by using `kubectl get pvc <pvcName>` and checking the `storageApplianceName` annotation. The value tells you which storage appliance the PVC is using.
+PVCs using the nexus-volume storage class can select the storage appliance to use for backing storage using the `storageApplianceName` annotation. If this annotation isn't present, the PVC uses the first storage appliance. You can check this by using `kubectl get pvc <pvcName> -o yaml` and checking the `storageApplianceName` annotation. The value tells you which storage appliance the PVC is using.
 
 If you wanted to create the PVC on the other storage appliance then you must delete and recreate the PVC, and then provide the correct annotation. There's no support for moving the volumes consumed by a PVC between storage appliances.
 
@@ -58,4 +58,3 @@ A CSN fails to create if the `nexusSharedStorageApplianceName` Azure resource ta
 1. Navigating to the aggregator rack and selecting Storage Appliance definitions.
 
 The `nexusSharedStorageApplianceName` Azure resource tag must match one of the storage appliances in the Storage Appliance definitions list. You must delete the CSN and recreate it with the correct Azure Resource tag to resolve this issue.
-
