Policies in vROPs enables analysis, automation, metric and alert settings to be applied to a set of objects.  These objects reside within custom groups (for more info on creating custom groups see https://vnuggets.com/2018/08/23/vrealize-operations-6-7-custom-groups).

vROPs comes with a set of OOTB policies which can be edited, copied or used to create other policies from.

Policy Inheritance

Every policy that is created has to be based from a parent policy.  This may mean the Base Settings policy or one of the other OOTB policies as shown in the screenshot above.  The tree view of policies shows the admin which policies are based on which parent policies.

The inherited settings of a parent policy can be overridden within a child policy. Similarly an admin may update the settings of a parent policy and those settings will flow down to any child policies that have been created from the parent as long as the child has not overridden the settings.  Got it?

vSphere Default Policy

The first policy that is auto-created and applied by vROPs when the vSphere Adapter is configured is the “vSphere Solutions Default Policy”.  This policy is applied automatically to every vSphere object that vROPs can see from it’s data collections, whether that be clusters, datastores, virtual machines etc.  It is based on the “Base Settings “policy (the root of all policies) meaning that it inherits all the settings from “Base Settings”.

Policy Contents

A policy is made up of the following areas:

Section 1 enables us to define which policy will be used as the basis for the current policy.

Once selected we can see the settings our policy will start off with in section 2 and also a summary of any settings specifically defined within this policy.

If there are settings in another policy we want to use but we don’t want to permanently depend on that other policy (in case somebody changes it for example) then we can import the settings from that policy rather than use it as the base policy.

Section 3 provides our analytical configuration.  By default it will define the risk level used when projecting out how long an object has before it runs out of capacity.  This can either be an aggressive calculation that carries more risk with it’s accuracy or a conservative calculation that is based on using the upper bounds of all estimates.

As well as the “Time Remaining” settings we can use section 3 to define the scoring thresholds for particular object types.  Here we have added the Virtual Machine object type.  Each one can be overridden from the defaults by using the padlock to unlock the configuration.

In this example we are changing the workload threshold for the warning stage to 70% rather than the default 80%.  This will mean a virtual machine object will be flagged with a warning status when it’s workload score crosses 70% (workload being whatever is the most constrained resource).

We can add more object types to section 3 as desired and override their settings as needed.

Section 4 covers virtual machine (workload) placement across clusters.  If this policy is applied to a custom group containing a datacenter then these settings will be used by vROPs to decide how to balance workloads across the clusters within the datacenter as well as determine how much room should be left as headroom in each cluster when making placement decisions.  Additional rules can be added using vCenter tags to restrict VMs to clusters that match the same tag configuration.

Section 5 allows us to select the metrics and properties this policy will collect and use which can then be used for our alert sand symptoms in section 6.

Each metric or property is either inherited for use based on the base policy from section 1 or is specifically disabled or enabled using the “Local” settings by changing the state entry.

Section 6 allows us to include or exclude symptom definitions and alert definitions.  If you have defined some custom symptoms in place of OOTB symptoms then you would exclude the OOTB symptoms from the policy and enabling the custom symptoms.  Custom alert definitions would also be handled in the same way.

Finally, Section 7 allows us to apply the policy to something.  Policies can only be applied to custom groups (with the exclusion of the vSphere default policy which by default applies to everything).  The required group can be selected however remember that a custom group can only have one policy applied to it.