Content Library · Docs

Docs Archive

Browse 129 Docs items in the NetApp Black Box content library, sorted newest first. Page 2 of 2.

Library JSON API

Sort by

Showing all 9 items on this page

Docs2025-01-01

2026-09-03-kb-ontap-nse-sed-fips-unlock

Source: https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/How_to_unlock_SED_and_FIPS_disks_using_NSE

NetApp Knowledge Base how-to for unlocking Self-Encrypting Drives (SED) and FIPS-validated disks using NetApp Storage Encryption (NSE) before disabling the Onboard Key Manager (OKM). Stepwise procedure: requires authenticating to OKM, exporting the authentication keys for the disk shelves, and re-issuing unlock commands at the SP/BMC level so each disk's KAS (Key Authentication Server) accepts the cluster's KMIP-style key. Article is part of the OKM↔NSE migration playbook — must be performed BEFORE OKM is turned off or all encrypted data on the disks becomes permanently inaccessible. Tag list includes SED, FIPS, OKM, NSE, and storage encryption; specialty is core ONTAP 9. Public index visible; detailed procedure gated behind NetApp Support login.

Open source

Docs2025-01-01

2026-09-03-kb-ontap-metrocluster-svm-kek-mismatch

Source: https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/SVM-KEK_key_mismatch_warning_in_ONTAP_MetroCluster_with_Onboard_Key_Manager

Diagnostic walk-through for the `km.okm.key.missing` EMS event and the `Internal Error. The local and partner clusters do not have the same list of SVM-KEKs` warning returned by `metrocluster check cluster show -check onboard-key-management -instance`. In a MetroCluster IP/FC setup with Onboard Key Manager (OKM) enabled, SVM-KEKs (the per-SVM key-encryption keys) must exist on both clusters or encrypted volumes at the surviving site cannot be unlocked after a site failover. Public-visible content shows the EMS message, the metrocluster check output columns (Result of the Check, Additional Information/Recovery Steps), and the actual event timestamp from August 2026 (8/18/2026). Article references the underlying MCC + OKM + SVM-KEK recovery workflow which TAC runs to re-mirror the SVM key set to the surviving cluster — critical content for anyone running MetroCluster with NVE/NAE at both sites.

Open source

Docs2025-01-01

2026-09-03-kb-ontap-ktls-handshake-limit-913

Source: https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/Repeating_ktls.cnxnHandshakeLimit_message_after_ONTAP_Upgrade_to_9.13

Specific ONTAP 9.13+ post-upgrade failure mode: EMS log fills with `[nodename: kernel: ktls.cnxnHandshakeLimit:notice]: ONTAP reached the maximum limit of N concurrent TLS connection handshakes. If this limit is reached, subsequent TLS connections will fail.` Often paired with `ems.engine.suppressed:debug: Event 'ktls.cnxnHandshakeLimit' suppressed N times in last NNN seconds`. Root cause is the kernel TLS (kTLS) handshake concurrency cap (170 by default) — typically hit when many NFS-over-TLS, SMB-over-TLS, or LDAP-over-TLS clients reconnect simultaneously after the upgrade. Public EMS excerpt and article framing are visible; the actual tunables and remediation steps are behind NetApp Support login. Tag the KB when triaging post-9.13-upgrade incidents where TLS connections intermittently fail.

Open source

Docs2025-01-01

2026-09-03-kb-ontap-flexvol-inode-max

Source: https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/How_to_increase_the_maximum_inode_count_or_files_for_a_flexible_volume

Canonical 167,502-view ONTAP KB for the dreaded `wafl.vol.outOfInodes` / `file system is out of inodes` error. Walks through inspecting current settings with `set advanced` then `volume show -vserver svm1 -volume vol1 -fields size,files,files-used,files-maximum-possible` and shows the relationship between FlexVol size and `files-maximum-possible` (typically 1 inode per 32KB of volume size by default). The procedure to increase the inode ceiling is `volume modify -vserver svm1 -volume vol1 -files <new-count>` — and the KB warns that the max possible is bounded by current volume size unless you grow the volume at the same time. Critical context: shrinking a FlexVol below its current `files-used` is blocked; you can only grow inodes, never reduce. (Public preview shows the diagnostic commands; full step list behind NetApp Support login.)

Open source

Docs2025-01-01

2026-09-03-kb-ontap-failover-io-interruption-vmware

Source: https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/What_is_the_expected_I_O_interruption_time_during_storage_failover

NetApp's official sizing guidance for the I/O gap during ONTAP storage failover (SFO) when running VMware ESXi on NFS or block datastores. Confirms the I/O interruption is "typically limited to a few seconds up to approximately 15 seconds" — well under VMware's default NFS datastore timeout of 60s and the typical FC HBA timeout of 30s. Practical consequence: datastores stay mounted, VMs do not power off, in-flight I/O is briefly queued and resumes once the partner node is serving LIFs. Admins should expect short latency spikes inside guest OSes and brief application slowness but no fault tolerance events. Sets expectations correctly so the failover doesn't get escalated as a fault — useful for VMware/NetApp converged stack SREs.

Open source

Docs2025-01-01

2026-09-03-kb-ontap-cluster-recovery-failure-cases

Source: https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/What_are_the_main_failure_cases_that_require_cluster-level_recovery_in_an_ONTAP_environment

Definitive NetApp answer on when ONTAP needs cluster-level recovery (RDB + root aggregate restoration), as opposed to node-level or aggregate-level recovery. Two representative cases: (1) multiple simultaneous disk failures in aggr0 exceeding RAID-DP/RAID-TEC tolerance — typically more than three disks failing at once or a shelf-level power loss that takes root disks down. aggr0 holds the ONTAP OS image and the replicated database (RDB), so RDB quorum can't be re-established. (2) simultaneous power outage in both HA pair nodes causing a dirty shutdown that leaves RDB inconsistent. Cluster recovery is rare but disruptive — knowing the exact triggers helps admins plan dual-PSU, dual-feed, and battery-backed cache strategies for their root shelves.

Open source

Docs2025-01-01

2026-09-03-kb-ontap-autosupport-smtp-delivery-failure

Source: https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/ONTAP_AutoSupport_Transport_SMTP_Delivery_Failure_Resolution_Guide

NetApp's official resolution path for "AutoSupport emails aren't reaching NetApp" — the SMTP transport branch of the ASUP troubleshooting tree. Starts with `autosupport show -node <node> -instance` to verify mailhost/from/to, then `system node autosupport check show` to validate the four ASUP delivery channels (HTTPS, HTTP, SMTP, OnDemand). If SMTP fails, walks through checking SMTP reachability to the mailhost, reviewing `notifyd.log` for SMTP errors, and inspecting `autosupport history` for delivery timestamps. A 13,169-view / 2-vote KB rated as core-specialty ONTAP 9 material — used by every TAC case where the customer can't tell whether AutoSupport was even attempted.

Open source

Docs2025-01-01

2026-09-03-kb-ontap-9-performance-resolution-guide

Source: https://kb.netapp.com/on-prem/ontap/Perf/Perf-KBs/ONTAP_9_Performance_Resolution_Guide

NetApp's official performance troubleshooting tree for ONTAP 9 — the canonical starting point whenever a customer reports slow I/O, latency spikes, or throughput regressions. The guide organizes the investigation into the standard ONTAP 9 perf flow: confirm whether the bottleneck is on the client/network path, the protocol layer (NFS, SMB, iSCSI, FC), the storage virtual machine, the volume/FlexVol, the aggregate/WAFL, or the disk/RAID layer. Each branch points to the specific KB article, EMS message, and PerfStat/Statistics counter families to look at next (e.g. `statistics show`, `qos statistics`, ` wafl_hya_perf`, `nfs3_histogram`, WAFL read/write latency histograms, object-store offload latency if FabricPool is involved). Tells you which ONTAP 9 commands to run before you open a support case so your ASUP bundle has the data TAC actually needs.

Open source

Docs2024-12-04

Elevating data privacy in Generative AI with NetApp (NetApp)

Source: https://www.netapp.com/blog/elevating-data-privacy-generative-ai/

NetApp technical blog on data-privacy architecture for generative AI workloads: ONTAP features (encryption, WORM/SnapLock, role-based access control, audit logging) that customers need to enforce when grounding LLMs in enterprise data. Includes sample policy mappings for GDPR/HIPAA and a reference architecture for SnapMirror-based RAG index replication between regions.

Open source