Perhaps you can convince your management to just allow you to update your vCenter to 6.0 U1. 

I may have stumbled upon a possible bug that I have not seen mentioned anywhere.  When the active policy count in vROps 6.x exceeds 20, forcing the list to a 2nd page, reordering of the policies fails with "DB active policy count doesn't match input policy id count".

I tested this multiple times, and dissociated policies from groups to reduce from 22 active policies to 20 and reorder functionality works.  This was performed several times and the error is repeatable.

Workaround:

1) Disassociate policies from groups/objects which you want to be at the bottom of the priority order and save.  Example:  Policy with priority order of 18 needs to be 21.

     - If you need to move a policy up, it is recommended that you reduce the active policy count to <=20 to regain drag and drop reorder capabilities.

2) Associate policies with groups/objects in the order in which you want them prioritized.  They will always be placed at the bottom of the list, above Default Policy.

I have been deploying vROps since February this year but have noticed some issues since late August with many new deployments. It is mainly in relation to resources within VM's and Hosts / Clusters. Some clusters will report all information correctly and others can have all hosts missing or only report back on certain hosts and VM's.

I have attached some examples of the issues that I am seeing regularly.

The following example (server names removed) shows that the CPU Recommendation and reclaimable information is missing:

On other clusters or for other customers it may only show one or two hosts in the cluster and misses the others completely.

Another problem I am seeing recently is that it is massively overestimating the CPU resources for hosts and VM's. In the following example a small cluster has 56 cores and it is recommending an upgrade to 149 Cores:

However, if you look at the above the stress zone graph, the requirements are way under anything that is being recommended. I am seeing this on lots of VM's and hosts where the CPU recommendations are massively over what the graphs are showing.  When we look in depth on the resource utilisation they do not match the recommendations.

The following is another example:

Previous assessments would have shown a recommendation to 5 or 6 CPU's, suddenly we are seeing an increase of double this up to 10 but the graphs and data don;t add up. I am seeing this problem on most recent deployments.

This also impacts the host rightsizing and massively gives the wrong information:

Suddenly we are going from saving 30% capex to increasing hardware requirements!

Again this has only started since September and the last vROPS version I checked was running 6.0.2.27777062 Build 2777062

I know there is a new version released and have been advised that this "SHOULD" fix this problem but this was all unofficial advice.

Questions:

• Has anyone else experienced this problem and which releases are producing the problem?
• Can anyone confirm that the latest release fixes these problems and is stable?
• Once you apply the update how long do we need to wait to receive consistent data? Will we need to wait 30 days until the old bad data has been replaced with true accurate data or does the update re-analyse the data and fix the reports. Or do we blow vROps away completely and do a fresh installation

I believe that the product is awesome and we have just hit a bit of a hiccup, I just have a lot of customers that I suddenly cannot explain what is going on!

Thoughts and feedback would be appreciated on the above

I am getting some here and there missing information as well, mostly for certain metrics.  I am inquiring as to why this is, but you are not alone.

On the stress zone, you may be interpreting the data incorrectly.  Using your example, you have a VM which has 10 GHz worth of procs (4 x 2.5).  You have your stress zone set as >70%, and the stress is 134%.  The pink area of the chart is the stress zone.  Anything within the pink is a breach of the stress threshold you have set in the policy associated with this VM.  On top of breaching the stress zone, this VM has actually demanded more CPU than is even allocated to it, peaking at 11.2 GHz.

Since your average demand is only 17.31%, you may want to take a look at your policy.  The stress for a Virtual Machine is obviously set to 70%, but is the sliding analysis set to Any or Entire Range.  If any, what is the peak period of time that you set?  If Entire Range, what is the amount of time you set in the time field of the virtual machine policy?

How the policies are set are EVERYTHING.  vROps tells you what you tell it to tell you.  You change that to 90%, and the recommendation will change.  Change the peak period, and it should change.

I have this exact issue, I tried your method and didnt work, maybe I´m doing something wrong because  I´m quite new on this tool.

When I create a new rule, this rule override the default ones? Or I have to remove them?

Thanks for the reply. All the settings are out of the box, no changes, standard installation. These shots have come from the base Analysis tab and then the Stress zone tab. In the past, the peaks have always reflected average demand and the spikes reflect the recommendations. I have selected no ranges, base console information is from the last 30 days.

However, I have noticed over the last 6 weeks that the recommendations don't match the spikes. Something has changed in the analysis. Previously the spikes in the graph would reflect the GHz recommended. in the example they don't. The Blue line recommended is 23.4 GHz but the spike demand is 11.2 GHz. With 4 CPU's configured this would point to one more vCPU being required to facilitate the spike and stress, 2 at a push. Definitely not 10!

Unless for some reason the system is reporting as if the settings have been changed - I will check this but I am seeing the same every week since the end of September, too much of a conicidence. This is also on every single deployment I have checked since then, same reports, same analyis and it doesn't add up. I am also getting customers pointing these anomilies out to me.

The Host Right Sizing information is being skewed massively when I see these anomolies, It really does seem as if some settings and thresholds have been changed but they haven't.

I was advised that there are known issues with this version and these should have been fixed with the latest version release. I just haven't had chance to verify the settings and to identify how long it will take to fix the anomilies. When I mentioned this to VMware they were aware of "problems" but wouldn't go in to too much detail as to what they know but have advised they will assist me personally but real world experience and support knowledge can usually be more beneficial.

It should have data there for you to analyse. Have you installed the latest update PAK file? There has been an issue with the previous version which resulted in missing data but not at the level you are seeing. It might help.

VROps gets data from vCenter as it happens. You usually see data pretty quickly but there is usually a lot missing for the first 7 to 11 days. 30 days is a safe time to get real analytics from this. Most of the data analytics is processed around 1am each morning, so unless the VM is off during this period you should have reports.

I just explore few of the option but the trend report is not proper . let see

larsonm, thanks for your reply.

Actually vrops tells me VMware vSphere with Operations Management Enterprise Plus for vRealize Operations

So by reading that I assume that he's not using the standard license... am I that wrong?

The blog is a a little older but you can see towards the top that it mentions the update is available. (Update: https://www.vmware.com/products/vrealize-operations/vrops-hol?src=management-blogTry vRealize Operations 6.1 here.)

All the marketing documentation points to the feature being available in 6.1, but I can not find it anywhere in the user manual.

Enterprise Plus refers to the edition of vSphere.  All versions of vSphere with Operations Management include vRealize Operations Manager Standard Edition.

"All the settings are out of the box" ... This is really the core of the problem.  vROps is not intended to be out of the box ready to go.  This is a common mistake that leads to people tossing vROps to the side stating it reports incorrectly.

To your specific issue .... It is running at 131% of it's 10GHz.  So it needs 13GHz to be at 100%.  But the threshold is 70%.  So you need closer to 20GHz to remain below the 70% on spikes and peaks.  That's just using basic math, not the advanced algorithms that vROps uses.  I would say that it needs at least 8, based on the default policy that it is applying.

My first recommendation would be to create a new policy which meets the criteria which you look to apply.  I believe the default policy applies the 70% capacity across Any 60 minute period by default.  Perhaps you want to change it to the Entire Range, or 80%.  Or maybe you don't want spikes and peaks considered, or maybe you want it to be 120 minute range.

I would clone the default policy, play with it a bit and apply it to this VM as a test case (just create a group with this single VM being the lone member, and associate the policy to that group).  It's the easiest way to start understanding how certain settings impact vROps recommendations.

Anyone?

I found the following document for the necessary firewall ports needed by vROPS

vRealize Operations Manager 6.0.1 Documentation Center

Could someone please explain a little clearer what these are needed for?

I'm not quite sure what is meant by "clients" for port 6061.  Are clients the VMs being monitored?

Many thanks!!

Robby

Just a little add-on is that the timing changed in vROPs and is now 10PM rather than 1AM as it used to be in vCOPs.

Hi,

I'm having trouble upgrading vROps from version 6.0.2 to 6.1. The 6.1 OS upgrade works fine but the 6.1 appliance upgrade fails at "Steps Completed" "4 of 9 - Preapply Validated"

I was unable to go from 6.0.1 VA to 6.1. However upgrading from 6.0.1 to 6.0.2 was successful (both OS and VA)

I can also confirm that there were no projects in place when doing the upgrade (from the release notes)

Upgrade does not complete

When upgrading an earlier vRealize Operations Manager deployment to this release, the cluster might become unresponsive with the System Status page continuously displaying Waiting for Analytics. The problem occurs if any of your version 6.0.x capacity projects have expired by having an implementation date that is now in the past.

Workaround: Before starting the upgrade, open the World> Projects page in version 6.0.x. When you display the page, vRealize Operations Manager updates the internal state of expired projects, and the unresponsive upgrade issue does not occur. If you have already started an upgrade and encountered this issue, contact VMware Technical Support for assistance.

Going through some log files in localhost:/var/log/vmware/vcops # I see

vcops_upgrade_20151020-142712.log

2015-10-20 14:36:01,477 - b2b - ERROR - updateCoordinator - programExit - Run post upgrade product scripts failed

vcops_upgrade_20151020-142712.log.1

2015-10-20 14:34:51,818 - INFO - No need to update service names on non-windows

2015-10-20 14:34:51,819 - INFO - directory "/usr/lib/vmware-vcops/suiteapi/extensions/suiteapi-telemetry-extension" does not exist.

2015-10-20 14:34:51,819 - ERROR - Completed stats post upgrade, exit code: 4"

2015-10-20 14:34:51,849 - b2b - DEBUG - updateCoordinator - runScript - exit code: 4

2015-10-20 14:34:51,849 - b2b - ERROR - updateCoordinator - runScript - Script command: "/usr/lib/vmware-vcopssuite/python/bin/python /storage/db/pakRepoLocal/vRealizeOperationsManagerEnterprise-6103038037/extracted/upgrade_scripts/VA/post/stats-post-upgrade.py" failed with exit code: 4

2015-10-20 14:34:51,850 - b2b - ERROR - updateCoordinator - run_upgrade_scripts - The post upgrade product script: "/storage/db/pakRepoLocal/vRealizeOperationsManagerEnterprise-6103038037/extracted/upgrade_scripts/VA/post/stats-post-upgrade.py" failed with exit code: 4

dbupgrade_20151020-143045.log

2015-10-20 14:34:28,490 - INFO - runScript:82 - stderr:

2015-10-20 14:34:28,490 - INFO - runScript:83 - exit code: 0

2015-10-20 14:34:28,490 - INFO - runScript:74 - Running command: /usr/java/default/bin/java -cp "/usr/lib/vmware-vcops/common/lib/persistence-1.0-SNAPSHOT.jar:/opt/vmware/vpostgres/current/lib/postgresql-9.3.jdbc4.jar:/usr/lib/vmware-vco

ps/common/lib/spring-aop-3.2.9.RELEASE.jar:/usr/lib/vmware-vcops/common/lib/spring-beans-3.2.9.RELEASE.jar:/usr/lib/vmware-vcops/common/lib/spring-context-3.2.9.RELEASE.jar:/usr/lib/vmware-vcops/common/lib/spring-core-3.2.9.RELEASE.jar:/

usr/lib/vmware-vcops/common/lib/*" -Dlog4j.configuration=file:/usr/lib/vmware-vcops/user/conf/persistence/log4j-sql-dbupgrade.properties com.vmware.statsplatform.persistence.util.sql.SqlDbUpgrade

2015-10-20 14:34:45,257 - INFO - runScript:81 - stdout:

2015-10-20 14:34:45,258 - INFO - runScript:82 - stderr: SLF4J: Class path contains multiple SLF4J bindings.

SLF4J: Found binding in [jar:file:/usr/lib/vmware-vcops/common/lib/slf4j-jdk14-1.7.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: Found binding in [jar:file:/usr/lib/vmware-vcops/common/lib/slf4j-log4j12-1.7.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: Found binding in [jar:file:/usr/lib/vmware-vcops/common/lib/vcops-suiteapi-client-1.0-all.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

SLF4J: Actual binding is of type [org.slf4j.impl.JDK14LoggerFactory]

Oct 20, 2015 2:34:28 PM org.springframework.context.support.AbstractApplicationContext prepareRefresh

INFO: Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@8bd1b6a: startup date [Tue Oct 20 14:34:28 AEDT 2015]; root of context hierarchy

Oct 20, 2015 2:34:28 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions

INFO: Loading XML bean definitions from URL [file:/usr/lib/vmware-vcops/user/conf/persistence/spring-sql-dbupgrade.xml]

Oct 20, 2015 2:34:29 PM org.springframework.core.io.support.PropertiesLoaderSupport loadProperties

INFO: Loading properties file from URL [file:/usr/lib/vmware-vcops/user/conf/persistence/persistence.properties]

Oct 20, 2015 2:34:29 PM com.vmware.statsplatform.persistence.SpringPropertiesUtil resolvePlaceholder

INFO: postgres is enabled for central db, override db.driver to be just local until code cleanup

Oct 20, 2015 2:34:29 PM com.vmware.statsplatform.persistence.SpringPropertiesUtil resolvePlaceholder

INFO: return local driver:/data/vcops/xdb/vcops.bootstrap

Oct 20, 2015 2:34:29 PM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons

INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@4c12331b: defining beans [propertiesHolder,postgresDataSource,org.springframework.aop.config.internalAutoProxyCreator,org.springfr

amework.transaction.annotation.AnnotationTransactionAttributeSource#0,org.springframework.transaction.interceptor.TransactionInterceptor#0,org.springframework.transaction.config.internalTransactionAdvisor,txnManager,upgradeActionExecutor

Manager]; root of factory hierarchy

Oct 20, 2015 2:34:45 PM org.springframework.context.support.AbstractApplicationContext doClose

INFO: Closing org.springframework.context.support.ClassPathXmlApplicationContext@8bd1b6a: startup date [Tue Oct 20 14:34:28 AEDT 2015]; root of context hierarchy

Oct 20, 2015 2:34:45 PM org.springframework.beans.factory.support.DefaultSingletonBeanRegistry destroySingletons

INFO: Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@4c12331b: defining beans [propertiesHolder,postgresDataSource,org.springframework.aop.config.internalAutoProxyCreator,org.springframework

.transaction.annotation.AnnotationTransactionAttributeSource#0,org.springframework.transaction.interceptor.TransactionInterceptor#0,org.springframework.transaction.config.internalTransactionAdvisor,txnManager,upgradeActionExecutorManager

]; root of factory hierarchy

2015-10-20 14:34:45,258 - INFO - runScript:83 - exit code: 0

2015-10-20 14:34:45,259 - INFO - runScript:74 - Running command: /sbin/service vpostgres stop

2015-10-20 14:34:46,519 - INFO - runScript:81 - stdout: Stopping vRealize Operations vPostgres Database...

Stopped vRealize Operations vPostgres Database.

2015-10-20 14:34:46,519 - INFO - runScript:82 - stderr:

2015-10-20 14:34:46,519 - INFO - runScript:83 - exit code: 0

2015-10-20 14:34:46,521 - INFO - <module>:308 - Completed Sql DB Upgrade

2015-10-20 14:34:51,653 - ERROR - <module>:337 - One or more of the DB upgrades failed, exiting with exit code: 2, continue for now

stats-post-upgrade_20151020-142925.log

2015-10-20 14:34:10,678 - ERROR - Script command: "/usr/java/default/bin/java -cp "/storage/db/vcops/tmpoa082L/*:/usr/lib/vmware-vcops/controller/plugins/*" -Dlog4j.configuration=/usr/lib/vmware-vcops/user/conf/persistence/log4j.properties -DALIVE_BASE=/usr/lib/vmware-vcops com.vmware.statsplatform.persistence.util.DBUpgrade adminRoleEnabled,dataRoleEnabled,uiRoleEnabled" failed with exit code: 2

2015-10-20 14:34:10,679 - ERROR - Master DB Upgrade failed with exit code: 2, continue to run master postgres DB Upgrade

2015-10-20 14:34:10,679 - INFO - Running Master Postgres DB Upgrade

2015-10-20 14:34:10,679 - INFO - Running command: /usr/java/default/bin/java -cp "/storage/db/vcops/tmpoa082L/*" -Dlog4j.configuration=/usr/lib/vmware-vcops/user/conf/persistence/log4j.properties -DADAPTER_HOME=/usr/lib/vmware-vcops/user/plugins/inbound com.vmware.statsplatform.persistence.util.CentralSqlDbUpgrade.CentralSqlDbUpgrade adminRoleEnabled,dataRoleEnabled,uiRoleEnabled

2015-10-20 14:34:16,437 - INFO - stdout:

2015-10-20 14:34:16,438 - INFO - stderr: SLF4J: Class path contains multiple SLF4J bindings.

SLF4J: Found binding in [jar:file:/storage/db/vcops/tmpoa082L/slf4j-log4j12-1.7.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: Found binding in [jar:file:/storage/db/vcops/tmpoa082L/slf4j-jdk14.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]

2015-10-20 14:34:16,438 - INFO - exit code: 0

2015-10-20 14:34:16,438 - INFO - Running Cassandra DB Upgrade

2015-10-20 14:34:16,438 - INFO - Running command: /usr/java/default/bin/java -cp "/storage/db/vcops/tmpoa082L/*:/usr/lib/vmware-vcops/common/lib/*" -Dlog4j.configuration=/usr/lib/vmware-vcops/user/conf/persistence/log4j.properties -DALIVE_BASE=/usr/lib/vmware-vcops com.vmware.vcops.dbupgrade.cassandra.CassandraDbUpgrade adminRoleEnabled,dataRoleEnabled,uiRoleEnabled

2015-10-20 14:34:26,116 - INFO - stdout:

2015-10-20 14:34:26,116 - INFO - stderr: SLF4J: Class path contains multiple SLF4J bindings.

SLF4J: Found binding in [jar:file:/storage/db/vcops/tmpoa082L/slf4j-log4j12-1.7.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: Found binding in [jar:file:/storage/db/vcops/tmpoa082L/slf4j-jdk14.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: Found binding in [jar:file:/usr/lib/vmware-vcops/common/lib/slf4j-jdk14-1.7.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: Found binding in [jar:file:/usr/lib/vmware-vcops/common/lib/slf4j-log4j12-1.7.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: Found binding in [jar:file:/usr/lib/vmware-vcops/common/lib/vcops-suiteapi-client-1.0-all.jar!/org/slf4j/impl/StaticLoggerBinder.class]

SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

I have even gone so far as to verify the MD5 check sum on the files to make sure they downloaded correctly.

I have done plenty of Googleing and there doesn't seem to be a resolution to this problem. Any help is welcome.

Thanks

Call GSS and open an SR, as it looks like the db upgrade failed. This ca be due to a numbers of reasons.

No, GemFire clients... aka. vR Ops nodes. vROps nodes need these ports open between one another, bidirectional. Remember, this is for v6.0.1... 6.1.0 needs additional ports.

v5 was largely relying on anomalies, KPI, workload, faults for Health of objects. v6 shifts to be largely Alert-based for influencing Health,Risk,Efficiency values. Alerts IMPACT these badge scores. Now on the data collection itself.. make sure you've got the proper perms to collect your data from vCenter with propagation enabled, with firewall ports 443, 8443, 10443 open to vCenter FROM the collecting vR Ops nodes. Specifically, give me a metric names and for which object types that you think are missing..

Workload placement becomes an action when you configure the workload placement section in the Policy.

Workload placement can be run on a number of containers, including the new Custom Datacenter org constructs.

Once you have the policy configured, you'll notice you can now run the rebalance action (and recommendations/actions) on supported containers. From there, give it a test drive on a dev/lab env and see how it flies!