2014-10-29 08:17 AM
2014-10-30 12:21 PM - edited 2014-10-30 12:23 PM
I think I have a resolution:
I saw another post where a user was experiencing something similar. In his case he was dealing with OCUM 5.2P2 and CDOT 8.2.1 (http://community.netapp.com/t5/OnCommand-Storage-Management-Software-Discussions/OCUM-5-2P2-and-cDOT-8-2-1RC2-question/m-p/44726/highlight/true#M9182)... For that user, waiting ended up being the answer - after some time the vserver/SVM information was again populated.
This gave me some hope that I could get things working again. I didn't think waiting would be the answer, since it has been a week since we upgraded the CDOT clusters to 8.2.1.
I went ahead and did an OCUM upgrade to 184.108.40.20627 (5.2.1RC2).
The upgrade went fine, however the 8.2.1 Clusters were still not reporting their vservers/SVMs (beyond each cluster root svm). I deleted one of the clusters from OCUM and re-added, and the SVMs are now being detected.
One thing I did notice, which might be directly related to the problems I had :
Within the 220.127.116.1147 (5.2R1P1) installation, when I looked at the OnCommand console web view, and the Operations Manager view, both interfaces still used the "Vservers" name.
Within OnCommand Console web view, under the Storage Tab, the list of object on the left included "Vservers.
Within Operations Manager,under Control Center / Member Details / Virtual Systems, the Reports were Vservers, all, Vservers Volume Capacity, etc.
Now with 18.104.22.16827 (5.2.1RC2) installed both interfaces list Storage Virtual Machines as the option, not Vserver. I am wondering if the 5.2R1P1 version was in some weird in-between state where it knew Vservers should be known as Storage Virtual Machines, but it did not yet have the Storage Virtual Machine category to report them in.
In any case 5.2.1RC2 and deleting the clusters from OCUM/OpsMgr seems to have cleared up the issue for me.