With a new year comes new things and I am delighted to announce the start of a vROps based webinar series. These will consist of a set of live webcasts on different topics around vRealize Operations Manager open to public to attend live or view the recorded sessions later. Personally I am delighted to get the chance to work with Sunny Duaon this new project. Sunny is a well known and respected Senior Consultant at VMware and can be found often on twitter @Sunny_Dua.
So if you are already familiar with vROps you will know you can now have multiple nodes in your cluster. 8 nodes if you are on versions 6.0.x 16 nodes if you are on version 6.1 Why does this matter if you plan to use SNMP with your vROps cluster? Quite simple really, what I discovered today is that even though you have a master node SNMP traps can and will be sent from all of the nodes to the destination you have configured.
I must admit I have been quite keen to get a look at vROps 6.1 so I was quick to upgrade my lab from 6.0 to 6.1 (with not problems I might add) and have a good look at the new bits and pieces. The bits I will cover briefly in this post are.. Upgrading from 6.0 EPO functionality Dashboards Automated actions (ON?) Upgrading from 6.0 Ensure you upgrade the OS of the appliance first (if you have one) - vRealize Operations Manager - Virtual Appliance Operating System upgrade (vRealize_Operations_Manager-VA-OS-6.
So vROps 6.1 has gone GA! What have the guys at VMware added? I have listed what I consider the hi-lights below The maximum of 8 nodes has been doubled to 16! SSO integration has been added (requires vSphere 6.0) **Support for SRM has been added ** vRealize Hyperic functionality has been added
One of the great new features included in vROps is High Availability, however when you look a little closer at how it works careful thought needs to go into whether you want to use it or not. I have had several discussions with my colleagues on the subject about whether you should or should not enable it in any given deployment of a vROps cluster. So the following are my thoughts and bullet points for you to consider when faced with same dilemma.
Recently I have been working with various products that compliment or are accessed by vCOPs/vROps via Management packs. As vROps is still fairly new in comparative terms to other products like vCOPs and VCE Vision, when planning migrations from vCOPs to vROps it is naturally important to check compatibility and what is required for a successful migration. If you are doing a greenfield deployment of vROps there is nothing to be concerned about, you simply need the VCE Vision appliance running version 2.
Recently I have been looking at William Lam’s excellent post on automating the deployment of vROps. After having a play around with it, to suit my own needs, I made some modifications to the Powershell script so it would support distributed switches. # William Lam # Edited by Simon Eady to support vDS # www.virtuallyghetto.com # Deployment of vRealize Operations Manager 6.0 (vROps)
For several months now we have seen glimpses of vROps by way of limited blog posts and the HOL demo’s so it was great to see it finally released. So what is it like out of the box? vROps 6.0 Release notes The first clear change is the move away from 2 VMs in a vAPP and consolidation down to 1 VM which is then easily scalable to more as you require.
vCOPs resources If you have spent time working with vCOPs you will be aware of the numerous and widespread resources out on the net to help you install and fine tune your deployment. Given there is a lot of content out there that is not always easy to fine immediately I wanted to collate a useful list for my own use and to share with others. Still a work in progress.
Recently I encountered this problem in a customer site whereby the logon to VCSA 5.5 would either time out, or take 3-5 minutes to actually log on. Running a netstat on the VCSA during the attempt to logon showed there was a SYN packet sent to the vCOps appliance on port 443 that never established a connection. Another check was attempting to connect using curl <https://> –k - this would time out.