Hi,
I've just upgraded my vRealize Operations to 6.2, and I'm working with two vCenter Servers – vCenter 5.5 Update 2b Build 2183111 (Windows OS), and vCenter Server 6 (Linux VCSA Appliance).
After the successful upgrade – the vCenter 5.5 stop collecting information (the adapter stuck on "Starting"), the vCenter 6 is fine and continue to collect information.
What I've done so far:
Anyone familiar with this issue and know how to solve it? I'll be glad to hear some tips/advices/workarounds/solutions to my issue.
Thanks! 🙂
Same issue here, did you get any answers?
My next option I think is re-register the adapters or call support...
My situation was slightly different than yours, as I had upgraded from 6.1 to 6.2, but I did experience the issue where I had a collector that would never complete starting. In my environment, I'm collecting data from 2 different vcenter instances. One of the instances refused to start completely. I tried to un-register & re-register, I also tried re-describing the adapter instance but neither action resolved the issue.
In the end, with help from Vmware I was able to resolve the issue by stopping and restarting collection of the individual objects managed by the problem vcenter adapter instance. I had to do it in small batches, say 10 or so at a time. If I tried to do larger batches , it would error out. This took a while, as in my case as I had a couple thousand objects to stop/start. But, in the end this did clear the issue.
To stop/start the individual objects, I just drilled down in Inventory explorer, to Adapter Instances->vCenter Server->(vcenter instance), and selected the objects there.
Vmware support wasn't really able to provide a good explanation as to why this happened. Hope this is of some help
Sounds pretty close to me - our vCenters are 5.5U3 (3000241), and it's happening on both adapters. This was also a 6.1->6.2 upgrade on the vROPS appliances. I should point out its even two separate vROPS environments we upgraded and both have this issue, so I wouldn't call it a "glitch".
The interesting thing is the adapters never seem to write anything into the logs even though they say starting, I'm hoping re-resister fixes it.
Thanks for the info - if it doesn't I'll log a support case.
It sounds a problem with adapter. Try to open a case on support to help you.
I ended up needing to recreate the adapter instances.
None of the objects migrated over clean, executing actions against them would throw errors "Work Item is NULL".
Recreating the adapters and preserving the data worked fine.
Have you tried just removing the vCenter adapter and re-adding it to vROps?
Did you see if all objects are "Collecting"?
I recreated all instances of the Adapter - so all the vCenter connections, then it worked fine and went back to Collecting.
My point was that there obviously is something in the upgrade that is not properly updating these instances. Not only do they not start after the upgrade, but they can't be reconfigured. If you try, you get "Work Item is NULL".
Just a quick follow up on this - even though the adapters showed started after a day or two we noticed the metric counts were not increasing - so we were still not getting any data.
I opened a VMware case and found out this is a known issue - the KB reference is KB 2144582. There is a hotfix available from support.
very good!
We had a similar problem with an update from 6.1 to 6.2.0a along with a Horizon adapter 6.1 to 6.2 (and then 6.2.1). We had our two VCenter adapters and the Horizon adapter all stuck at Starting... with no end in sight. When trying to register the VCenter adapters, we got a Work item is null error message. So something was really off under the hood.
We opened a support call with VMware and in the end, KB2144582 seemed to point to our problem. The agent gave us a command to run in postgres to change some values, but at the same time, I used one of the solution here to remove all the broken adapters and add them back. So I can't say if the command sent to us was the definitive fix or te remove/add of the adapters (I know, don't make two changes at once ). In the end, everything came back working.