Tuning vCOps for your environment – Part 3 – Creating and Applying Policies

In my last Post Part 2 – Badge Tuning I discussed the importance of tuning badges via polices to accurately reflect different workloads in your environment. In this post I will discuss the importance of Intelligent Operations Groups and creating your own polices, and finally the role of the Default Policy.

Now a few people might be stating this is 101 stuff whats the go? However the reason I am blogging on this is I see a lot of customers not taking advantage of this functionality and as a result having an environment which is noisy and useless.

The Default Policy (The King of Policies):
De-fault my two favorite words in the English language. The Default Policy is exactly that, is the policy that is applied by default to all vCOps objects where another policy is not explicitly applied. As a result OOTB the default policy is the policy that is applying to all vCOps objects until you specify a different one, and even in environments where numerous polices are created for different environments, functions and use cases the default policy generally ends up staying the dominant one.
Because of this tuning the Default Policy is probably the most important policy to get right, after which other polices can be cloned from it.

There are three questions relating to the Default Policy I get a bit so I will bring that up too.
Q: Why even have other polices when you can just tune the heck out of the default one?
A: Easy. It is almost impossible to have one policy that fits your whole environment. For example a Production Alerting and Capacity Management policy is going to be completely different to a Dev/Test Policy.

Q: How do I know what Policy is applying to an object?
A: Simply select the Parent object in the navigation window and Select Environment -> Members.

Q: What should I set to my Default Policy to?
A: As a bonus I will provide my most commonly used Default Policy recommendations in my final post of the vCOps series.

Creating Intelligent Operations Groups:
Before we go crazy creating policies for different reasons one of the first steps is to create groups for the polices to apply to. Policies can only be applied to groups so even you want to apply a policy to an entire cluster it needs to be in a group. It is also useful to know that all vCenter Folders are automatically created as groups, so these can be leveraged if your great at organizing your VMs inside vCenter. However my complaint with Folders in vCenter is a VM can only be in one folder, where the same is not true for a group.

I’m not going to go into the step by step procedure for creating groups as this is well covered in the vCOps documentation (Pg 76). However I will provide my tips when creating groups:

  • Dynamic Groups are preferred as they auto update as VMs are added into your environment. However they usually rely on naming standards or something common to link objects together with. vCenter Infrastructure Navigator (VIN) can also be used to automatically discover applications and populate dynamic groups accordingly.
  • Use preview button (shown in pic) to check that you rule logic is sound before creating the group.
  • If you have objects in multiple groups record in the name or description which one has the policy applied. A Object can only have one policed applied.
  • Groups also provide a great way of mini-dashbaords for functions or applications without the need of the Custom UI.


Creating and Applying Polices:
Again I’m not going to go into the step by step procedure for Policy creation as this is well covered in the vCOps documentation (Pg 86). However again here is my tips on the topic:

  • Clone the Policy off your Golden Default Policy (Default Policy recommendations will be made at the end of the series) and only change the badges or policies that are needed to be changed. Don’t start from a scratch everytime.
  • Don’t create policies for the sake of it. Eg. Every Cluster should have its own policy. This creates unnecessary overhead if all policies need to be updated for a common change.
  • Label or record in an external document what changes have been made from the default policy. Descriptions like “Exchange Policy” don’t assist others in knowing what you have changed.

Q: If I have a VM in two groups and each has a policy assigned how do I know what Policy will take effect?
A: When two or more policies are applied to an object the policy order determines which policy is applied. The policy order is set by dragging around the polices in the manage policies Window as shown below.


Final Word:

  • Use policies where appropriate applied to groups that you create. This is the heart of Tuning vCOps.
  • Understand which Policies are applying on which objects.
  • Get the Default Policy right! (Help will come for that later)

In my next Post I will begin discussing the important subject of Capacity Management Models and Tuning vCOps to give capacity assessments based on your environment and your designs.

Leave a comment


  1. Saintdle

     /  January 22, 2014

    cheers for the info, i have a customer site I’ve been working on, and i want to show them the time savings they can gain by letting VCOPs do the monitoring for them and can concentrate on other things.

    This will go a along way in one, helping me set it up, and two explaining the product to the customer

  2. I REALLY want the datastore policy that you describe in part 2 and for me a newbie with VCOPS can’t figure out how to properly accomplish in your limited discussion in part 3.

    Any chance you could expand on that some more or show an example?



Leave a Reply

Your email address will not be published. Required fields are marked *