Error Object Not Found For TopoDriver In Topology-SAM After Upgrade
Article ID: 451703
Updated On:
Products
Issue/Introduction
You experience a missing TopoDriver object in a Topology-SAM domain after upgrading to version 25.4.7.
ERROR MESSAGE: MR2-E-MR_WHILE_OPERATION_INVOKE-While invoking operation start in object / MR-OBJECT_NOT_FOUND_EX-Cannot find object / MR-CALL_ON_NULL_OBJECT-Tried to make a call on a NULL repository object, typically referencing an object of the form GA_DaemonDriver::<domain>_Topo-Driver.
SYMPTOMS:
GA_DaemonDriver::<domain>_Topo-Driver does not exist (absent from dmctl getI GA_DaemonDriver output), and attempting to invoke start on it returns the error above.
The domain manager's log shows an ASL-W-ERROR_RULE_REPLACE-Redefining rule '<garbled text>' warning referencing the same domain's <domain>_Driver object — this is the diagnostic signature of this specific issue, distinct from the object-not-found error above, which is a generic consequence rather than the cause.
Only affects domains configured without an active Notification-List subscription (see Cause).
CONTEXT: Observed after upgrading to 25.4.7, on a domain not affected by any prior upgrade.
Environment
VMware Smart Assurance 25․4․7
Cause
The domain's Driver object loads a version-specific ASL rule file to process its configuration. If a local override of that rule file exists (per Smarts' standard base/local customization mechanism) and has not been reviewed or reconciled with newer base/stock releases across one or more subsequent product upgrades, running that outdated script under a newer engine version can produce corrupted, dynamically-constructed internal identifiers — which can prevent successful (re)creation of dependent driver objects, including the TopoDriver.
This specifically affects domains whose configuration does not have an active Notification-List subscription directive (e.g., a sub <list>/n line commented out rather than active) — these domains take an alternate internal processing path from domains that do have one. If the rule file behind that alternate path has an unreconciled local override, only domains using that path are affected, while sibling domains using the other path remain unaffected — which is why this may appear on only one domain even when others were upgraded identically.
Resolution
PREREQUISITES: Administrator access to the SAM domain manager; read access to $BASEDIR/smarts/local/rules/ and $BASEDIR/smarts/rules/.
Confirm the object is genuinely missing (not merely stopped):
dmctl -s [system-id] getI GA_DaemonDriver
Check whether the expected driver name appears at all.
Check the domain manager's log for the corruption signature:
grep "ERROR_RULE_REPLACE" [logfile]
A warning of the form ASL-W-ERROR_RULE_REPLACE-Redefining rule '<garbled>' tied to the affected domain's _Driver object is the confirmed signature of this issue.
Identify the rule file actually in use for the affected domain's Driver object:
dmctl -s [system-id] get GA_RuleSet::<domain>_Driver-RS::fileName
Check for a stale local override of that file under $BASEDIR/smarts/local/rules/.... Compare it against the current base/stock version of the same file (same relative path under $BASEDIR/smarts/rules/...). A local override that is many versions old, with no genuine customer-specific customization in it, is the likely cause.
If confirmed: retire the stale override (e.g., rename it with a .retired-<date> suffix) so the domain manager falls back to the current base/stock file. Restart the affected domain manager (or the relevant driver, if a targeted restart is supported) and confirm the missing driver is recreated and the ERROR_RULE_REPLACE warning no longer appears.
VERIFY SUCCESS: driver appears in getI GA_DaemonDriver output; ERROR_RULE_REPLACE no longer appears in the log after a subsequent restart.
Additional Information
PREVENTION: At every major product upgrade, use sm_migrate's review step to check every flagged local override — not just apply it automatically. A local override that shows no genuine divergence from the current base file (only staleness) should be retired rather than carried forward indefinitely; carrying forward a stale override across multiple upgrade cycles is what allowed this specific defect to remain latent for years before a later engine change exposed it.
Feedback
