What is a policy?
A policy in vROps is a set of rules (Analysis, Automation, Alerts & Symptoms) which are applied to a series of objects.
You can create groups of objects and assign a different policy for different groups.
On initial setup, there will be a “Default Policy” It is generally a good idea to create new policies based on the default so that you can “roll back” to or at least inspect the default vROps policy at a later time.
Creating a policy based on an existing policy is a form of inheritance. For example, policy 1 might be your default company policy, but you might want to turn off alerts for a group of development VMs or other objects. Simply create a new policy (policy 2) based on policy 1. At this time, policy 2 is exactly the same as policy 1. Now edit policy 2, disabling whichever alerts you want to turn off. The final step is to create a new group and place the development VMs into this new group, then assign policy 2 to this new group.
Be sure to try this out in a test environment or free hands on lab to ensure you understand the impact:
vRealize Operations (vROps) – Hands on LabWalkthrough
First, create a group for your objects
- Navigate to Environment > Custom Groups > + Icon
- Give the group a name: Development VMs
- And a type such as: Environment
- Specify the membership criteria, this can be done by selecting VMs in a particular folder or if they contain a certain character set. There are many ways you can define the group membership though
- Under “Objects to always include / exclude” you can specify individual objects, however, this would not be dynamic, ie the objects are statically set here so keep this in mind
- Ensure you use the preview button to test your work
- Hit Ok to save
Next, create the policy
- Navigate to Administration > Policies > Policy Library (at the top) > + icon
- Give the new policy a meaningful name and description
- Under “Start With” specify the policy you wish to inherit settings from. In this example, we are inheriting settings from the vSphere Solution’s Default Policy
- Select “Select Base Policy” Ensure “Configuration Inherited from Base Policy” is selected
- From now on, to change a setting from the default, you will need to select the lock icon to unlock that item and enabling editing
- Under “Analysis Settings” you can modify the Time Remaining calculations
- You can also edit Workload Automation in the same way
- Under “Collect Metrics and Properties” this is where we can disable the collection of various data from objects. This is useful to save space or bandwidth, especially if you have many objects managed by vROps. To change the collection state, search for the attribute to turn collection off for and under the State select “local” with the red icon. Here, inherited means use the value from the base policy as defined earlier. “Local” with the green tick means define it locally. This is essentially how you would turn collection on if it is disabled in the base policy
- The same applies to “Alert / Symptom Definitions”. You can change the state of individual alerts to turn them off.
- For symptoms, you can change the thresholds here too. For example, for Development VMs, you might only want to be notified of a critical alert if the guest filesystem is 99% full rather than the default 95%. You would simply change this here by:
- Changing the state to Local with the green tick
- Change the condition to override
- Finally, adjust the threshold value accordingly
Now that we have finished building our policy, we can “Apply Policy to Groups” simply select the group containing all the relevant objects and after 15 minutes the new policy will be applied.
To test which objects have been assigned to the new policy, navigate to Administration > Policies > Active Policies
- Select the new policy
- Select Related Objects in the bottom pane
- Groups will show you what groups the policy is assigned to
- Affected Objects will show you all objects that the policy is applied to
This concludes this post. As always, let me know if you have any questions or feedback.
