Automatically place ESXi hosts in maintenance in vROps using properties

This has come up in a number of discussions with customers and a few VMware field employees and hence I wanted to blog about this and use this as a standard answer going foward :-)

Use Case - An administrator wants to disable alerts on a ESXi host which has been put into maintenance mode in vCenter. This is to avoid any alerts on this ESXi hosts inside of vROps, while the admin wants to continue to collect the metrics on this ESXi host.

Goal - The goal is to do this automatically without any manual changes in vROps. As soon as a host goes into maintenance in vCenter, vROps should know this and should stop alerting on the host in vROps.

Solution - This can be achieved by using Custom Groups and Policy and a one time configuration.

1- Create a new policy in vROps named "Hosts in maintenance policy". This policy can be created under the default policy.

Go to Administration -> Policies -> Policy Library 

2- Select the default policy and click on the + sympbol to add a new policy.

3- Give it a name and description as shown below.

4- Click on Alerts and Symptom Definitions and filter the list of aletrs with only host system alerts. We want a filtered list so that we can disable these in one go.

5- Now press CTRL + A on the keyboard to select all of them, you can also click on Actions -> Select All.

6- Click on Actions - > State -> Disable 

7- Click on Save and now you can see he new policy under your default policy.

8- Create a new custom group named "Hosts in Maintenance". Use the following creiteria to dynamically add members to this custom group based on ESXi host property which vROps collects every 5 minutes.

Click on Environment -> Custom Groups -> Click on the + Sign to add a new custom group.

Make sure to select the policy "Hosts in maintenace policy" which we created earlier.

9- Click on Preview to see if you are getting results. If you have any hosts in mainteance moed in your environment, you will see results like me :-)

10 - Finally go into Administration -> Policies -> Active Policies and set the newly created policy at priorty 1 rank.

Now, as soon as you will put hosts into maintenance mode in vCenter, within the next 5 minutes they will be be discovered as being in maintenance inside vROps and they will be added into the cutom group. Once they are a part of the group, the maintenance policy with all alerts disabled will be applied to these hosts and you will not see any alerts on them in vCenter, till the time they are in maintenance. Once they are out of maintenance, they will be moved out of this group subsequently. All of this would no longer require any manual intervention, once configured.

Do note, that if you add any new alerts (in future) related to hosts, you would need to make sure that they are disabled in this policy.

Hope this helps...

Share and spread the knowledge..

vROps Webinar 2016 - Part 7 : Working with Alerts & Symptoms

Time to release the recording for the latest part of the vROps Webinar Series.  We completed the 7th session of the series where we spoke about vRealize Operations Manager Alerts and Symptoms. 

Alerts as we all know would always remain the heart and soul for the operations teams to run the data centers, whether old school or the modern software defined.

In all cases you need alerts and more importantly you need meaningful and actionable alerts. In this part of the series, Simon and myself concentrated on making you aware of the alert constructs in vROps and as usual share experiences around how we help customers leverage the strong feature set of vROps to customize alerts and related symptoms, recommendations and actions to drastically reduce the Mean Time to Resolution of issues.

The journey so far has been fantastic and we would continue to add more content as we progress into the rest of the year. 

Stay tuned for more and enjoy this recording!!!

Till next time.. Have a Good One!!

vROps Webinar 2016 - Announcing Part 7 : Working with Alerts & Symptoms

Time to announce the next part of the year long webinar series on vRealize Operations Manager. With the last part of the series, we started focusing on content withing vROps. We will continue the trend and talk about a major function of vROps a.k.a Alerts. Alerts is the most used and most ab-used part of vROps, and with this session we want to give you some insights on the entire life-cycle of the alerting function of vROps.

We will touch upon, defining alerts, making sure they are actionable, understand how they are manged within vROps and also talk about the components which make up an alert. 

Day & Date          : Friday, 29^th July 2016

Time                     : 1:30 PM - 2:30 PM  (SGT)

Event                    : vROps Webinar 2016

Topic                     : Part 7 : Working with Alerts & Symptoms

Speakers               : Simon Eady / Sunny Dua

WebEx Link          : JoinWebEx Meeting

NOTE - Don't forget to mark your calendars by saving the Date!! Feel free to forward the invite to anyone who might be interested. It's open to all!!


Sharing & Spread the Knowledge!!

Reset out-of-the-box content during vROps upgrade!

VMware recently release vRealize Operations Manager 6.2 (now 6.2a with the recent patch). If you are on a version of vROps 6.x or above and trying to upgrade to the 6.1 or 6.2, you will get an option during upgrade to reset out-of-the-box content when you install the software update.

Here is how the setting would look like during the upgrade:-

The release notes over here explain this setting:-

I have had many customers ask me the meaning of this statement as they are concerned about losing customizations they have done in their vROps environments. 

This statement means that, if you are using any of the out-of-the-box Alerts, Symptoms, Recommendations or Policies which came with the product when you first installed it, checking this option may reset them back to default (with newer settings wherever applicable).

This also applies if you have just renamed the out of the box content. A best practice would be to clone out of the box content and then do further customizations to avoid resets of your valuable customizations.

So if you have not modified the existing Alerts, Symptoms, Recommendations or Policies and have created everything from scratch then those configurations would not be harmed by checking this option. It is a good idea to check this option to get the latest and the greatest released with the product, however be CAREFUL and assess your Alerts, Symptoms, Recommendations & Policies before taking a call.

A GOOD PRACTICE to manage Alerts, Symptoms, Recommendations & Policies would be to NEVER customize the one's available out of the box, but to Clone from the existing one's and customize the cloned Alert, Symptom, Recommendation or Policy. This way you will never be dependent on the out of the box content and would never be impacted if VMware provides new updates to those in the upcoming releases. Another benefit is that, you will never mess up the original configuration in case you are trying to test drive stuff.

Share & Spread the Knowledge!