AIQUM 9.18P3 MetroCluster acquisition fails with TreeMap NullPointerException

Based on NetApp Knowledge Base: AIQUM 9.18P3 MetroCluster acquisition fails with TreeMap NullPointerException (last updated 21 October 2026). Only claims present in that public section are asserted as fact.

What the KB documents

On 21 October 2026 NetApp published a KB article for a specific acquisition failure in Active IQ Unified Manager 9.18P3. The stated scope is narrow and worth reading exactly:

• Active IQ Unified Manager 9.18P3 (AIQUM)
• REST-based acquisition through Cloud Agent
• ONTAP MetroCluster
• FabricPool or aggregate object-store configurations

The symptom: AIQUM fails to acquire one or both MetroCluster clusters. Baseline collection completes, and then the G-mode conversion stage fails. That ordering matters — see the triage section below.

The signature in au.log

The KB quotes the log verbatim. The first line names the missing object before the exception appears:

GModeAggregateObjectstoreConfigMapping - can't find aggregate uuid
  <partner_aggregate_uuid> on cluster name <cluster_name>
GClusterBuilder - ExecutionException encountered on Builder
java.util.concurrent.ExecutionException:
java.lang.NullPointerException: Cannot invoke
  "java.lang.Comparable.compareTo(Object)" because "k1" is null
    at java.util.TreeMap.compare(TreeMap.java:1569)
    at java.util.TreeMap.addEntryToEmptyMap(TreeMap.java:776)
    at java.util.TreeMap.put(TreeMap.java:785)
    at java.util.TreeMap.put(TreeMap.java:534)
    at com.onaro.sanscreen.acquisition.schema.NodeMap.put(NodeMap.java:51)
    at ...CModeAggregateObjectstoreConfigMappings.add(...:19)
    at ...GAggregateBuilder.buildModel(GAggregateBuilder.java:221)
NetAppOCIEDataSource - GMode Conversion exception:
  0 out of 1 devices acquired successfully.

NetApp also notes a variant, depending on aggregate processing order, where the trace opens instead with java.util.Objects.requireNonNull(Objects.java:209) and java.util.TreeMap.put(TreeMap.java:809). The rest of the stack is identical.

Our reading of the trace

Two things stand out, and both are inferences from the trace rather than statements in the KB.

First, the missing item is a partner aggregate UUID looked up by cluster name. The mapping being built is aggregate-to-object-store — the join AIQUM needs so a FabricPool-backed aggregate on one MetroCluster site is understood relative to its partner. When that lookup misses, the code puts a null key into a TreeMap. A TreeMap sorts on insert, so a null key cannot even be stored: the NullPointerException is thrown inside put, not returned as a handled "unsupported configuration" result.

Second, the consequence is total, not partial: 0 out of 1 devices acquired successfully. There is no degraded acquisition where the local cluster is monitored and the partner is dropped. The build step that fails is GAggregateBuilder.buildModel, upstream of anything AIQUM could display.

Why MetroCluster plus object store is the trigger

Plain MetroCluster acquisition does not appear in the "Applies to" list on its own — the fourth bullet is what narrows it: FabricPool or aggregate object-store configurations. If you run MetroCluster without any object-store-backed aggregates, this signature should not apply to you. If you do run them, the aggregate inventory on one site includes aggregates whose identity is only resolvable through the partner cluster, which is precisely the lookup that logged "can't find aggregate uuid".

Background on the two moving parts: MetroCluster reference and FabricPool reference. For how object-store-backed aggregates are counted and tiered, see aggregate capacity.

Triage before you open a case

The log ordering is the useful part. Baseline collection completing tells you the REST path, Cloud Agent connectivity and ONTAP credentials all worked — the failure is in conversion, not collection. So time spent re-checking firewall rules, user roles or Cloud Agent registration is time spent on the wrong layer.

• grep au.log for GModeAggregateObjectstoreConfigMapping and GMode Conversion exception to confirm you have this signature rather than a different acquisition error.
• Pull the two placeholders out of the log: the partner aggregate UUID and the cluster name it could not be found on. Those are the identifiers NetApp support will ask for first.
• Inventory object-store-backed aggregates on both sites, and note which ones exist only on the partner.
• Re-running acquisition without changing anything is unlikely to help: the same lookup misses the same UUID.

The KB's resolution section is gated behind a support sign-in, so this page deliberately does not describe a workaround or a fixed release. If the signature matches, open a case citing the KB URL above.

Context: a run of 9.18P AIQUM defects

This is not an isolated entry in the AIQUM KB. The same area already documents AIQUM 9.18P2 API Gateway strips quota report data on collection GET to /storage/quota/reports and AIQUM 9.18P+ snapshot backups are reporting as failed despite being successful. Three separate 9.18P-era collection-and-reporting defects in one KB neighbourhood is a pattern worth noting if you are planning a 9.18P rollout: the pain is in data fidelity and acquisition, not in the monitoring UI.

What to watch

Two open questions: whether the fix arrives as a patch release, and whether the KB's resolution section later becomes public. Until one of those happens, treat AIQUM 9.18P3 against MetroCluster with object-store aggregates as a configuration to test on a non-production instance first, and keep the au.log evidence from any failure.

Sources: NetApp KB — AIQUM 9.18P3 MetroCluster acquisition fails with TreeMap NullPointerException (public sections: Applies to, Issue).