Tag Archives: vCOPS

Quick Fix: VCSA Web Client 6.0 Throws Monitoring Errors

This quick fix post is for those out there who are still using vCenter Operations Manager 5.8.x and are or thinking about deploying or upgrading to vCenter 6.0…I came across this annoying situation all of a sudden while working on a new vCenter instance when the Web Client started to report the error shown below.

This can be ignored by clicking no and you will still be able to operate most areas of the Web Client but you will find that Monitoring and Health pages fail to load and give you a generic Error #2036 as shown below.

It took me a while to realize that the error was related specifically to the monitoring modules and it finally clicked in my head that the error started happening when I Registered the vCenter against my lab vCOPs instance. I was still running vCOPs (not vRA) and the instance hadn’t been upgraded to the latest build. Having a look through the VMwareKBs I came across KB 2111224 which explained the cause.

This issue occurs because vRealize Operations Manager versions prior to 5.8.5 are not supported in the vSphere 6.0 environment.

Upgrading the vCOPs Appliances to build 5.8.5-2532416 sorted the issue and I was able to browse through the Web Client without the error and have the integrated Health Monitoring work without issue.

References:

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=2111224&sliceId=1&docTypeID=DT_KB_1_1&dialogID=850159080&stateId=0%200%20850161293

vCOPS 5.8: Critical Data Collection Bug

UPDATE: VMware Global Support supplied me with vCOPs 5.8.0 Hot Fix 01 Build 1537842 which is available via a support request. This is a complete .pak update so you will need to go through the upgrade process as per usual.

The issue of the missing data has been resolved, however I did need to go through and remove a heap of duplicate entity types in the Custom Dashboard. I have a fully functional vCOPs platform now. Hopefully no more bugs in this build!

Like most…I jumped to upgrade vCOPs from 5.7.x to 5.8 when it went GA mid December. Initially the upgrade completed without issue and the four vCenter’s registered looked to continue collecting data as expected.

# To cut to the guts of the error scroll to the bottom on the post.

Shortly after the upgrade I went through and performed an upgrade of vCenter from 5.0 to 5.1 in one of our sites. Upon completing the upgrade and having a look at the Custom Dashboards we have setup, I noticed that 90% of the hosts in the recently upgraded vCenter where showing as white boxes (no data)

Looking through the Analytic VM collector logs I found these entries that seemed to point to a connectivity/communication issue between vCOPs and the Hosts.

After going through a painful couple of support calls with VMware support where they where insistent the issue was with the vCenter (have you tried turning it off and on) and/or a disk space issue on the Analytic VM. They suggested it was a well known upgrade bug that can be resolved as per below.



Off the bat I knew this wasn’t my issues because initially on upgrade I didn’t have the issue. While I waited for support to try and diagnose the issue via vCOPs support log bundles, I assumed that the issue was in the data…possibly a bad row in the database relative to a host/vCenter.

I removed the affected vCenter from vCOPs Admin Registration Tab and ran the following command on the UI VM that I picked up from @h0bbel‘s Post here:

 

The command ran for about 20-30 minutes and returned as being successful. When I went back into vCOPs the affected vCenter’s hosts had returned and was actively collecting and reporting data…however I now saw a number of other hosts across multiple vCenters showing showing the same problem!

I contacted VMware support again and had the case escalated which resulted in the admission that there was a newly discovered (probably through my persistence in regards to the case) bug in 5.8 and that I was experiencing all the symptoms.

Issue in 5.8 where we have the below symptoms:

  • One or more ESXi/ESX hosts are no longer present in the vCenter Operations Manager inventory.
  • ESXi/ESX hosts are missing from the vCenter Operations Manager inventory.
  • Child objects of missing ESXi/ESX hosts such as virtual machines and datastores are present in the vCenter Operations Manager inventory.
  • This issue occurs when you place the ESXi/ESX hosts into Maintenance Mode in vCenter Server and then take the hosts out of Maintenance Mode.

Review the Below KB:
http://kb.vmware.com/kb/2068303/

So, at the moment there is no resolution or fix and the workarounds are pretty nasty! …basically you will be modding database entries and taking snapshots of the Analytic VM.

I just got off the phone with VMware support in Palo Alto and got told that a hotfix was being worked on and should be available soon. Once released to me, i’ll update this post with the final resolution.

vCenter Operations Manager 5 – UI Time-out Settings

A little after vCenter Operations Manager 5.0 went GA I posted this forum thread in regards to the default time-out value of the Web UI…Thanks to ILIO and VEIgel for follow-up posts with the initial solution, which at this time wasn’t documented. This is now covered in the release notes for 5.0.1 under known issues. But for those who haven’t read through the issues see the below to adjust the UI Time-out on vCOPS 5.0 (and now 5.0.1). The default time-out value is 30 minutes.

To change the default timeout value in the vSphere UI in the vApp:

  1. On the UI VM, edit /usr/lib/vmware-vcops/tomcat/webapps/vcops-vsphere/WEB-INF/web.xml and adjust the value for session-timeout parameter. Minus one (-1) results in an infinite timeout ” the session will not expire at all.
  2. Restart the Apache Tomcat web server by running the command: service vcopsweb restart

With the release of 5.0.1 it looks like any customizations you may have done get overwritten, so this process will have to be repeated upon every update. I’ve read posts about having to save any custom dashboards you may have created as well.

As a side note, I’ve noticed that by default you are able to use the login credentials relative to the vCenter instance(s) you have registered in the admin console…however I’ve found that when I added vCenters that use different LDAP sources the UI won’t let you login with any previously working LDAP account and you will need to log in with the default admin account…not sure if that’s a bug, or by design…I was surprised that it picked up user auth without any additional config from the first vCenter registered. In my example I had three vCenters registered, the first two had common LDAP profiles, while the third was standalone…

sources (1)