Netapp Operations Manager 4.0.0 - Not reporting on two filers

[sequeirad]

Have setup two new filers.

Added them to Operations Manager 4.0.0. running on a Windows 2003 server machine.

Operations Manager found them but it is not reporting on volumes or any other data under File Systems.

It does show the Aggrs under Aggreagtes but I need to collect volume info and that does not show up under File Systems.

Any ideas?

[sequeirad]

I guess this has stumped everyone?

[sequeirad · Accepted solution]

resolved the issue finally WITHOUT upgrading to newest version of DFM...

Here is what I did...

Dfm service stop

Dfm service start sql

Dfm host delete -f <object_id_associated_with the filer>

Dfm service start

Dfm host add <filer_name_or_ip>

Both filers are reporting volume level info now.

[kryan]

As I am sure you are aware, you have purged all historical data related to these filers by performing this “delete –f” action.

Bug3676432 will allow data to be collected some time, but there is no way to guarantee that collection continues other than upgrade to a version fixed for it (4.0D2 and higher).

In other words, the data collection could stop working in the future and it could have simply started working again without any change to your server.

[sequeirad]

Guess I wasnt sure what to ask for in my initial post and should have said that old data did not really matter.

Anyway, I am happy its reporting now

[fletch2007]

DFM database has stale information for a host (it believes snapmirror sync is not licensed - blocking vfiler migrations to this 3250 Ontap 8.1.2 node)

When I attempt the dfm host delete -f <ID> I get the following error:

C:\>dfm service stop

Service: watchdog stopped.

Service: server stopped.

Service: scheduler stopped.

Service: monitor stopped.

Service: eventd stopped.

Service: http stopped.

Service: webui stopped.

Service: sql stopped.

C:\>dfm service start sql

Service: sql started.

C:\>dfm host delete -f 152

Error in DELETE FROM objects FROM objects, volumes, vfilers WHERE volumes.hostId = vfilers.vfId AND volumes.volId = objects.objId

AND ( vfilers.vfId = 152 OR vfilers.vfHostId = 152 ) : (-198) [Sybase][ODBC Driver][SQL Anywhere]Primary key for row in table 'obj

ects' is referenced by foreign key 'objId' in table 'objectToDisplayItemMap'

Error: Failed to remove irt-na02.stanford.edu(152). [Sybase][ODBC Driver][SQL Anywhere]Primary key for row in table 'objects' is r

eferenced by foreign key 'objId' in table 'objectToDisplayItemMap'

C:\>dfm host list -a na02

ID   Type                     Host Name                           Host Address                              ProductId    Deleted

---- ------------------------ ----------------------------------- ----------------------------------------- ------------ --------

152 Active/Active Controller na02               11.65.64.114                             1573765081   Yes

Any idea how to resolve this?

I opened case 2004057388 on this

If I attempt to re-add/refresh, the stale license info persists for this node

(the delete, re-add worked for the partner node)

thanks

[russc73]

@fletch2007 - did you manage to resolve your issue?. I'm getting the same error when i try and delete -f a filer;

dfm host delete -f xfiler

Error in DELETE FROM objects FROM objects, volumes, vfilers WHERE volumes.hostId = vfilers.vfId AND volumes.volId = objects.objId AND ( vfilers.vfId = 54544 OR vfilers.vfHostId = 54544 ) : (-198) [Sybase][ODBC Driver][SQL Anywhere]Primary key for row in table 'objects' is referenced by foreign key 'objId' in table 'objectToDisplayItemMap'
Error: Failed to remove xfiler(54544). [Sybase][ODBC Driver][SQL Anywhere]Primary key for row in table 'objects' is referenced by foreign key 'objId' in table 'objectToDisplayItemMap'

[dirkschmiedt]

Hello russc, we had the same problem. 1) Analysis: dfm query run "select * from objectToDisplayItemMap" will show you the contents of the table, e.g. "userName","sourceTable","objId","defaultDisplayItem" "root","1","1","28" = 1 = DFM-Server "root","1","3405","73" = 3405 = Our Problemfiler "root","1","23846","81" = 23846 = A Volume of our Problemfiler "root","1","63880","80" = 63880 = A Volume on another filer More Informations can be seen by using: dfm detail OBJID | grep obj (Linux) dfm detail OBJID | find /i "obj" (Windows) e.g. "dfm detail 23846" shows that it is an objectId for a Volume of our problemfiler: ... objComment objCreationTimestamp 2016-01-26 04:20:16.000000 objDeleted 2016-01-26 04:40:12.000000 objDeletedBy root objDisappearedSince objFlags 5 objFullName FILERNAME:/VOLUMENAME <--- !!! objId 23846 <----!!!! objName VOLUMENAME <---- !!! ... objStatusTimestamp 2016-01-26 04:40:16.000000 objType Volume sysObjectID .1.3.6.1.4.1.789.2.3 ... 2) Resolution: We had to delete the objids belonging to our problem filer ( 23846 and 3405 in our case ) from objectToDisplayItemMap # dfm query run -f "delete from objectToDisplayItemMap where objId=23846" # dfm query run -f "delete from objectToDisplayItemMap where objId=3405" 3) Control: The two "bad" entries are gone: # dfm query run "select * from objectToDisplayItemMap" "userName","sourceTable","objId","defaultDisplayItem" "root","1","1","28" "root","1","63880","80" 4) Success 🙂 dfm service stop dfm service start sql dfm volume delete -f 63880 # Maybe you can skip this step dfm host delete -f 3405 dfm service start Please leave a short reply if this short guidance helped you, too. Good luck! Dirk Schmiedt

[dirkschmiedt]

Hello russc, we had the same problem. 1) Analysis: dfm query run "select * from objectToDisplayItemMap" will show you the contents of the table, e.g. "userName","sourceTable","objId","defaultDisplayItem" "root","1","1","28" = 1 = DFM-Server "root","1","3405","73" = 3405 = Our Problemfiler "root","1","23846","81" = 23846 = A Volume of our Problemfiler "root","1","63880","80" = 63880 = A Volume on another filer More Informations about your ObjectIds can be seen by using: dfm detail OBJID | grep obj (Linux) dfm detail OBJID | find /i "obj" (Windows) e.g. "dfm detail 23846" shows that it is an objectId for a Volume of our problemfiler: ... objDeleted 2016-01-26 04:40:12.000000 objDeletedBy root objDisappearedSince objFlags 5 objFullName FILERNAME:/VOLUMENAME <--- !!! objId 23846 <----!!!! objName VOLUMENAME <---- !!! ... objStatusTimestamp 2016-01-26 04:40:16.000000 objType Volume sysObjectID .1.3.6.1.4.1.789.2.3 ... 2) Resolution: We had to delete the objids belonging to our problem filer ( 23846 and 3405 in our case ) from objectToDisplayItemMap # dfm query run -f "delete from objectToDisplayItemMap where objId=23846" # dfm query run -f "delete from objectToDisplayItemMap where objId=3405" 3) Control: The two "bad" entries are gone: # dfm query run "select * from objectToDisplayItemMap" "userName","sourceTable","objId","defaultDisplayItem" "root","1","1","28" "root","1","63880","80" 4) Success 🙂 dfm service stop dfm service start sql dfm volume delete -f 63880 # Maybe you can skip this step dfm host delete -f 3405 dfm service start Please leave a short reply if this short guidance helped you, too. Good luck! Dirk Schmiedt

[dirkschmiedt]

Hello russc, we had the same problem.

1) Analysis:

dfm query run "select * from objectToDisplayItemMap" will show you the contents of the table, e.g.

"userName","sourceTable","objId","defaultDisplayItem"
"root","1","1","28" = 1 = DFM-Server
"root","1","3405","73" = 3405 = Our Problemfiler
"root","1","23846","81" = 23846 = A Volume of our Problemfiler
"root","1","63880","80" = 63880 = A Volume on another filer

More Informations about your ObjectIds can be seen by using:
dfm detail OBJID | grep obj   (Linux)
dfm detail OBJID | find /i "obj" (Windows)    
e.g.
"dfm detail 23846"  shows that it is an objectId for a Volume of our problemfiler:
...
objDeleted 2016-01-26 04:40:12.000000
objDeletedBy root
objDisappearedSince
objFlags 5
objFullName FILERNAME:/VOLUMENAME <--- !!!
objId 23846 <----!!!!
objName VOLUMENAME <---- !!! ...
objStatusTimestamp 2016-01-26 04:40:16.000000
objType Volume
sysObjectID .1.3.6.1.4.1.789.2.3
...

2) Resolution:
We had to delete the objids belonging to our problem filer ( 23846 and 3405 in our case ) from objectToDisplayItemMap

# dfm query run -f "delete from objectToDisplayItemMap where objId=23846"
# dfm query run -f "delete from objectToDisplayItemMap where objId=3405"

3) Control: The two "bad" entries are gone:

# dfm query run "select * from objectToDisplayItemMap"

"userName","sourceTable","objId","defaultDisplayItem"
"root","1","1","28"
"root","1","63880","80"

4) Success 🙂

dfm service stop
dfm service start sql
dfm volume delete -f 63880 # Maybe you can skip this step
dfm host delete -f 3405
dfm service start

Please leave a short reply if this short guidance helped you, too.

Good luck!
Dirk Schmiedt

Sorry for the predecessing bad layout. The Communities Web-Site is screwed up without allowing javascript. 😞