Storage systems
The storage register: what earns a row and what is only counted, how a system is detected automatically, and how the suggested upgrade window is derived.
A row in the register is the system. The rule that decides what earns a row is written once and holds for the whole family:
An object earns a row when a change can be scheduled against it, or when it is the only thing connecting two other rows.
A volume is neither, so it is not a row — it is a count in a column. Order of magnitude is the reason: an enterprise storage system holds thousands of volumes per controller, and a register with a row for each is a log, not a register. Capacity pools are kept, as a list inside the card rather than as a screen.
A dedicated backup appliance is a storage system whose role is Backup, not a family of its own. The protection policy itself — what is protected, under what policy, and when a restore was last tested — is a backup service.
The columns
| Column | What it says |
|---|---|
| System name | The system's identity, and its record key |
| Vendor | The vendor, as the source reports it |
| Platform | ONTAP, PowerStore, PowerMax, FlashArray… |
| Role | Primary · Secondary · Backup · Archive · Object · Files · DR |
| Status | The five status values shared across infrastructure |
| Site | Where the system sits |
| Utilization | One meter over Used and Raw capacity |
| Controllers | The controller count. The basis for the derived upgrade window |
| Pools · Volumes | Counts only |
| Protocols | FC, iSCSI, NFS, SMB… as separate chips |
| Model · Serial number · Version | The system's identifying detail |
| Support ends | The recorded date; turns red once it has passed |
| Owning team | Who is responsible for the system |
Pools, Volumes, Protocols, Model, Serial number, both halves of the utilization meter and Owning team are not in the default set. They are added through the column picker, and they are always in the export.
Capacity is stored in GB and displayed in TB once it passes 1024. Two units for one quantity is how a total comes out 1024× wrong exactly once, so the conversion is a display decision made in one place.
The serial number has no quick filter. One distinct value per row is not a filter, it is the column again.
Automatic detection from the equipment register
A system already in the equipment register is detected automatically and appears here with no configuration at all. Two tests have to pass: the equipment record must be classified as storage, and the model must name a system family the vendor publishes.
The double test deliberately excludes Fibre Channel directors. An FC director does belong in the storage band on the connection map, but it is not a thing you schedule a controller upgrade with a capacity pool against — and promoting eight switches into "Storage systems" is exactly the sort of confident wrong answer the product is built to refuse.
A system present in both registers carries the same record key in both. The connection map folds it into one node, and the storage card offers a link to the equipment record.
The derived change window
For a nondisruptive ONTAP upgrade, the product derives a suggested change window from the controller count. It is the only object in the product that gets a derived window.
The formula is shown, not only the result:
(controllers × stabilization wait) + (controllers × controller reboot) + checks and overhead
| Term | Default | Charged | Basis |
|---|---|---|---|
| Stabilization wait | 8 minutes | Per controller | Standard |
| Controller reboot | 30 minutes | Per controller | Convention |
| Checks and overhead | 30 minutes | Per upgrade | Convention |
Only one of the three terms is the vendor's. NetApp's documentation states that the upgrade waits eight minutes after each takeover/giveback cycle so that client applications can recover from the pause in I/O, and adds that this is a tunable parameter (-stabilize-minutes). The other two terms are product defaults nobody published, and they are labeled "Convention" in the table itself. The row marked "Standard" carries a link to its source; the row marked "Convention" carries a link to nobody. The total is never presented as a vendor-derived figure.
Four more things the calculation says out loud:
- The result is rounded up to a quarter hour. Windows are booked in quarter hours, and rounding down would suggest a window the work does not fit into.
- An odd controller count is stated explicitly. The last controller has no partner to take over for it, so upgrading it is disruptive. That is not an error — a single-controller system is a real configuration — but it is not smoothed over either.
- At eight controllers and above the result is reported as an upper bound. At that size the vendor switches to a concurrent batch method, and the concurrency factor is not documented on the page cited. Rather than divide by a number nobody published, the serial figure is shown with an "upper bound" label.
- A platform with no model gets no window at all. Running ONTAP's arithmetic against a PowerMax would produce a confident number about a procedure nobody has described.
Every term can be changed on screen and the result updates immediately. That change is local and is not saved — it changes what is drawn, never what is stored, and the panel says so. A site that has measured its own controller reboot records the value on the system card, and the server-side calculation follows it.
The change window travels with the collision warning: when a storage upgrade overlaps a patch window for servers whose storage sits on that system, the warning carries the calculation too — because how long the upgrade needs is what makes the overlap actionable rather than merely true.
Updated
This page is the file content/docs/en/v1/infra/storage.mdx