Setting the file. One moment.
Skill 08 · Azure Local Multi Rack
Subchapter 8.4
references/safety-rules.mdMarkdown2 KBView on GitHub
Multi-rack instances host large-scale production workloads across shared racks, a shared SAN, and a managed network fabric. A single change can affect hundreds of machines.
Start every investigation with show/list commands and ARG queries. Establish the current state before proposing any change.
Ask for explicit user confirmation before anything in this table.
| Action | Why it is risky |
|---|---|
| Network fabric changes | Fabric config is instance-wide; errors can isolate racks or break east-west traffic. |
| Isolation domain create/update/delete | Alters L2/L3 segmentation for running workloads. |
| Route policy changes | Can withdraw or import routes affecting north-south connectivity. |
| Bare metal machine power, restart, reimage, replace | Removes capacity and can move or destroy workloads. |
| Rack-level operations | Affects every machine in the rack. |
| Storage appliance / SAN operations | Shared by all compute racks; risk of data loss. |
| Cluster Manager or NFC changes | Control plane for the whole instance and, for NFC, potentially multiple instances. |
| VM power, delete, or disk operations | Direct workload impact. |
| Custom location or extension changes | Breaks the workload control path. |
Multi-rack is in preview. Do not assert that an operation is supported, reversible, or GA-backed without confirming in current documentation. Tell the user when guidance depends on preview behavior.
Before giving any procedure, confirm the deployment is multi-rack. Applying standard Azure Local procedures to a multi-rack instance — or the reverse — produces commands that fail or, worse, act on the wrong control plane.
Collect subscription, resource group, region, cluster name, Cluster Manager, NFC, rack identifiers, and affected machine or VM IDs before drawing conclusions. Never infer fabric or SAN health from Azure Resource Health alone.