Smarts SAM: Service Assurance Manager topology driver to the underlying domain never stops once it starts; Smarts IP AM discovery does not synchronize with Smarts SAM unless the AM domain is restarted
search cancel

Smarts SAM: Service Assurance Manager topology driver to the underlying domain never stops once it starts; Smarts IP AM discovery does not synchronize with Smarts SAM unless the AM domain is restarted

book

Article ID: 304080

calendar_today

Updated On:

Products

VMware Smart Assurance

Issue/Introduction

Symptoms:


Smarts SAM topology driver to the underlying domain never stops once it starts

Smarts Service Assurance Manager (Smarts SAM) topology driver to the underlying domain never stops once it starts
After the Smarts IP Availability Manager (AM) domain completes discovery, the Smarts SAM topology synchronization to the Smarts IP AM domain starts, but sometimes the SAM Topo_Driver to the AM never stops running

Smarts IP AM discovery does not synchronize with Smarts SAM domain unless the AM domain is restarted

A topology synchronization statement similar to the following is not seen in  the SAM domain logs:

Topology-Sync Started From: <AM-PM-DOMAIN>



From the SAM domain, running the following command states that the topology driver to the underlying AM domain is in a RUNNING state:

dmctl -s <SAM-DOMAIN> get GA_DaemonDriver::<AM-PM-DOMAIN>_Topo-Driver::state
GA_DRIVER_RUNNING



Environment

VMware Smart Assurance - SMARTS

Cause

This can occur when the Smarts SAM topology driver running on the presentation layer waits indefinitely for a response from the underlying Smarts IP domain. When no response is received, the topology driver will fail to synchronize the topologies, resulting in a mismatch between the number of topology elements available in the underlying domain and the presentation layer.

Resolution

In Smarts SAM 8.1 Patch 6 (HF6), a topology timeout parameter (TimeOutTopo <n>) was introduced so that the Smarts SAM topology driver will discontinue topology synchronization when there is no response from the underlying domain within the timeout period, and the topology will be synchronized in the next iteration. If you encounter this issue, EMC recommends that you upgrade your environment to Smarts SAM 8.1 Patch 6 or later, and enable the timeout parameter as specified in the following section.

Enabling the Smarts SAM topology timeout parameter
To prevent the Smarts SAM topology driver from waiting indefinitely for a response from an underlying domain, the topology timeout parameter (TimeOutTopo <n>) must be enabled and set to the desired value (in seconds). By default, this parameter is not enabled. To enable the timeout parameter, the parameter must be enabled in the dxa configuration file of corresponding domain (for example, dxa-sam.conf for SAM domains), and a value must be set. For example, if the timeout needs to be configured to 60 seconds, then the parameter TimeOutTopo with value 60 (TimeOutTopo 60) must be set in the dxa configuration.

This can be done as follows:

  1. Open the domain dxa configuration file for editing in sm_edit. The following shows the path to the dxa configuration file for SAM domains:

    <BASEDIR>/SAM/smarts/local/conf/ics/dxa-sam.conf
     
  2. Find the following entry in the configuration file:

    # Set timeout for remote server connection only if topology driver waits# indefinitely for underlying domain to respond.


    #TimeOutTopo 600 <--- Uncomment this line:
     
  3. Set the desired value and comment out (remove the '#' character) the TimeOutTopo line. The following shows the TimeOutTopo parameter enabled and set to 2 minutes (120 seconds): 

    TimeOutTopo 120


Additional Information

Please note that your environment may have a custom dxa-sam.conf file that your Global/Pres SAM is using.  If this is the case for you please use that dxa file not the GA described in this article.