One of the characteristics of a software defined datacenter (SDDC) is the use of policy based management. With policy based management you describe how your SDDC should behave. In an SDDC you don’t want to focus on the management of individual components, but you want to describe how the infrastructure should act and catch this in a policy. You can link a policy to relevant objects, for example VMs, storage or networking components.

Policy based management is included in different aspects of the VMware SDDC. Amongst others vSphere, NSX and vSAN leverage policies. VMware vRealize Operations also uses policies to determine the behaviour of the tool. In this article I will have a closer look at how policies are implemented in this operations management tooling.

The default policy and additional policies

After the initial installation a default policy is create in vRealize Operations (vRops). This policy is initially linked to all the objects that are monitored in vRops. However, you can (and should) create additional policies and link them to certain objects that are grouped together in a custom group. Of course you first have to create these custom groups, the option is found under the environment menu option. Maybe you first want to create additional Group Types under Administration, Configuration, Group Types.

In the example below you the see the default policy “viktorious-default-policy”, and you there are three other policies called Tier 1, Tier 2 and Tier 3.

In this case these policies represent specific settings that are related to Tier 1, Tier 2 and Tier 3 clusters and virtual machines. The Tier 1 policy in this example is linked to the Custom Group Tier 1 (Gold): all the VMs that are in the Tier 1 (Gold) Custom Group use the settings that are in the Tier 1 policy. (If you’re wondering where these policies are coming from, you might want to have a look at the Operationalize your World program here). Of course a custom group can contain a great variety of objects. In this example the custom groups are linked to the objects that are in a custom datacenter. It’s up to you if you want to create a specific policy for certain storage volumes; just put them in a custom group and link a policy to the custom group.

Policies and inheritance

Probably you’ve noticed the tree like structure in the previous example. The structure represents another important characteristic of policies: inheritance. The Tier 1 policy inherits all the settings of the viktorious-default-policy, so in case you don’t change anything to the Tier 1 policy it would be exactly the same as the viktorious-default-policy. This is probably something you don’t want, but initially the result of the policy would be the same. Note: there’s a root policy in vRops called the Base Settings policy; every “first level” policy is based on this one. You cannot edit this Base Settings policy, some itmes are automatically added to this policy (more on this later).

The contents of a policy

Let’s have a look on what’s in a vRops policy. When you open a policy you got a wizard presented that includes 8 steps.

In the Getting Started tab you can set the name and description of the policy and you can also configure the base policy on which the policy is based. It’s mandatory to select a base policy, the lowest level here is the Base Settings (root) policy.

The Select Base Policy tab shows you a policy preview. It’s about what metrics & properties, alarm definitions, symptom definitions and custom profiles are inherited from the base policy. It also shows you what configuration(s) are defined (changed) in the current policy. If nothing has changed, there are of course no changes. You can choose to apply all the changes from another policy to the current policy by leveraging the “Override settings from additional policies” option.

Analysis settings gives you the option to configure the way objects are analyzed in your environment. By default you get the settings that are inherited from the base settings. You can unlock these settings and change them if required. For example, if you want to change how the cluster capacity is calculated you have to select the Cluster Compute Resource Object, go to Capacity Remaining, click the lock and change the settings as required.

Workload automation is about the settings that are used in the Workload Balance dashboard. With Workload Balance you optimize the load on your cluster by moving VMs between available clusters.

Collect metrics and properties contains metrics, properties and super metrics that are collected by vRops. Metrics and supermetrics are dynamic values that change every 5 minutes (the collection interval for vRops), while properties contain more static information. Notice that if you’ve configured a new supermetric, you first have to enable the supermetric in the policy/policies that are/is linked to the object(s) to which the supermetric is applicable to. You can configure:

• The state – Enable or disable the (super)metric/property or use inheritance;
• KPI – Determines if the metric is een KPI or not. If a KPI is violated it will generate an alert;
• DT – Determines if the metric leverages the dynamic threshold feature in vRops.

Alert / symptom definitions is about which alerts and symptoms are enabled in the policy. If you create a new alert it is automatically added and enabled to the base profile. So a new alert will be active by default (this is a big difference with a new supermetric).

The Custom Profiles let you add custom profiles to a policy. A custom profile is used for capacity planning purposes in vRops. For example, you can define a specific standard size for a virtual machine or ESXi host.

The last option, Apply Policy to Groups, let you link the policy to one or more custom groups as discussed earlier in this topic.

With these eight options you can configure your policies as you want and get the max out of vRops! I hope this was helpful.