V4V - vCenter Operations for Horizon View Dashboards disappearing

[steffen_richter]

Hi guys,

we are having some strange issues with a V4V installation. Everything has been up and running for nearly exactly 2 days (minus 4 minutes) after the V4V adapter has been installed onto vCOps 5.7. The informations are:

vSphere: 5.0

View: 5.1.1

vCOps: 5.7.0

vCOps for View: 1.5

Registration of vCOps to vCenter done and checked

License added to vCOps-vApp

V4V adapter instance created (and still there, am also still able to create a new V4V adapter)

V4V broker agent installed and paired

V4V dashboards have been available in Custom UI, used them

today V4V dashboards disappeared and are missing from the Custom UI

Pairing got checked (works), vApp shutdown and powered on, license is still applied

Logging in as an user with role "Administrator" or "Operator" only shows vCOps Advanced/Enterprise default dashboards, but no more V4V dashboards are available or configurable

Supsect log file entry in vCOps Custom UI v4vadapter.log:

2013-04-17 12:25:33,122 ERROR [RMI TCP Connection(74)-xx.xx.xx.xxx] (1394) com.integrien.adapter3.V4V.V4VAdapter.onTopoRefresh - Exception in onTopoRefresh
java.lang.NullPointerException
at com.integrien.adapter3.V4V.TopoWrapper.getUserDesktopByMachineID(TopoWrapper.java:646)
at com.integrien.adapter3.V4V.TopoWrapper.replaceViewTopo(TopoWrapper.java:380)
at com.integrien.adapter3.V4V.AdapterBrokerMessageServer.onTopoRefresh(AdapterBrokerMessageServer.java:66)
at com.vmware.vcops.adapters.view.net.BrokerMessageServerImpl.onTopoRefresh(BrokerMessageServerImpl.java:67)
at sun.reflect.GeneratedMethodAccessor985.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
2013-04-17 12:25:33,122 ERROR [RMI TCP Connection(74)-xx.xx.xx.xxx] (1394) com.integrien.adapter3.V4V.V4VAdapter.onTopoRefresh - Context is <context pod_id='ccf9b8ea-b866-4669-a75e-9aa21e022a6e' ver='1.0' />

Anybody can help?

BR

Steffen

[IamTHEvilONE]

Did you login as a different user to the /custom UI?  if need be, login as the admin account to see if it has access to it.

It would be strange for the Dashboards to disappear without deleting them ... if you have multiple instances of vCOps, make sure you are logging into the correct one.  I've had that happen before.

[steffen_richter]

Hi Jon,

thanks for your reply.

We only have that one installation over there, so no chance logging into to the wrong vCOps instance. The „admin“ user also did not had the Dashboards anymore. Thats very strange, especially because everything was up and running, accessed by different users other than „admin“ and worked the day before the issue occured. No matter which user now did log in, we only had the „default“ dashboards from an Adv. or Ent. vCOps installation.

Only thing I found out is that the issue arised approx. 2 days after installing the V4V-pak-file. To be exact, 2 days minus 4 minutes after the installation. May just a coincidence, but… you never know. I was able to export the V4V-dashboards from another V4V installation in another environment/customer and import them here, so the customer can at least use the product now. We now collected the logs and filed an SR. If we receive a solution/update/workaround/whatever, I´ll update the thread.

BR

Steffen

[dhomoki]

I do not think that the log entry is not related to the dashboard problem.  Are you seeing this consistently in the log, or was this only seen 1 time?

[steffen_richter]

Nope, this log file only shows up once. And I labeled it "suspect" . You ask why? Well, we were not able to pin down when EXACTLY the dashboards disappeared, but they definitely worked 2-3 hours before this log entry and maybe 2 hours later we discovered the error/missing dashboards.

After this log entry, all log entries are repeating. We power the vApp down, and up again, and we see that in the log (remember, V4Vadapter.log is it where this comes from) but nothing else besides the log entries of the poweron and poweroff. I am also not sure that this log entry is related to the issue, but my only suspect so far.

We did not had much time to check each individual log afterwards, but as this should not happen and we found a workaround, we collected the logs and opened up a SR. So far no resolution, if I get one, I will let you know here.

BR

Steffen

[IamTHEvilONE]

I'd probably open a ticket with support at this time to see if there is anything that can be done.

[steffen_richter]

Done right after this post as mentioned ^^. Strange behaviour, hopefully they´ll find the root cause.

[IamTHEvilONE]

yeah, it would be good to note if there are any remaining Resources (like vms/pools/etc) in the Environment > Overview panel.  which would show data still coming in, we just don't have a display mechanism for it.

totally odd, and not something that's easy to work via the forums.

[steffen_richter]

Totally agree. I thought I at least try, and if we find a resolution/explanation in the end (no matter how, even through support maybe), others can find the resolution more easily.

vCOps itself was and is still running fine, the vSphere UI was fully functional and the Custom UI was also accessible. Only the V4V dashboards were totally gone from the Custom UI and the default Custom UI dashboards were there now. After importing the V4V dashboards from another V4V installation, we were able to again monitor the View environment. And AFAIK, no data was lost, we did not had a gap. Really seems to be an UI-related issue.

We´ll see!