Part 1 and Part 2 of the “Maintenance Mode in vRealize Operations” blog series leveraged features and functionalities of vROps and vSphere which are directly related to ESXi maintenance to fulfil the requirements.

What if you cannot use “Enter Maintenance Mode” in vCenter simply because there is no such option for e.g. Virtual Machines, Datastores or Clusters but your use case requires some kind of maintenance mode in vROps?

In this part we focus on this kind of scenario. In case you do not have to deal with such scenarios, no worries, your time won’t be wasted, you are going to learn how to use vCenter Tags and Custom Attributes in vROps.

The use case for this blog post is:

“In case of VM/Datastore/Cluster maintenance (whatever “maintenance” might be) I do not want to receive any alerts for the affected vROps objects.”

As always during assessment we collected following additional information:

• There might be several objects in maintenance at the same time
• The team doing the maintenance has read-only access to vROps UI
• The team doing the maintenance is able to edit vSphere Tags or Custom Attributes for the objects in maintenance
• Automation could be used but is not mandatory
• Metrics and properties need to be collected during the maintenance.

Obviously, we cannot use the OOB vROps Maintenance feature described in Part 1 as this would violate the last requirement and the vCenter team would need additional permissions in vROps. The vROps property “Maintenance State” we already used in Part 2 is not an option here, as this property is available only for Host System objects.

We need another property to designate objects in maintenance. This is where vSphere Tags and/or Custom Attributes come in handy.

The ingredients for one possible solution are:

• vSphere Tags and Custom Attributes – Interface for the vCenter team to start the host maintenance
• vROps Policy – place where we modify the behavior of vROps with regard to distinct objects
• vROps Custom Group – place where we group objects to apply a vROps policy to them

In Part 2 I have described (simplified) the model of Objects, Custom Groups and Policies in vROps.

Step 1 – Create a vROps Policy which implements the requirements.

In our case the requirement is to disable all alerts for Virtual Machines / Datastores / Clusters etc. during maintenance hence we need a vROps Policy in which we are going to disable the corresponding alert definitions.

A new policy is being created based on an existing one, so only few changes will be needed to tweak the default behavior of vROps. In the following picture we see alert definitions for Virtual Machines as an example. Previous parts describe the procedure of creating and modifying the vROps policy.

Step 2 – Create vROps Custom Group which will contain objects being in maintenance.

Again, “maintenance” describes here any work being done on objects which requires certain alert definitions being disabled temporarily.

In Part 2 I have already described how to create a vROps Custom Group. I will skip the common details here and focus on the membership criteria which is different in this scenario.

Now we have two options:

• vCenter Custom Attributes
• vSphere Tags

To understand the differences please see:

https://www.virtuallyghetto.com/2015/01/custom-attributes-vsphere-tags.html

There are also differences in vROps when it comes to the properties reflecting both concepts.

vCenter Custom Attributes

Custom Attributes are easy to use in vROps but the handling in vCenter might be cumbersome.

Let’s assume we want to conduct some kind of maintenance on certain VMs and a Datastore. In vCenter we assign an appropriate attribute to the objects we want to set into maintenance. Type “Global” allows us to use the same attribute on different object types.

After the next vROps collection cycle has been completed, this custom attribute is available as property.

And this is where the confusion begins, vCenter Custom Attributes are vROps Custom Tags properties.

These properties are easy to use in vROps Custom Groups membership criteria definitions. Extra tip, if you cannot find the property in the list presented by vROps as “common denominator”, please use the object picker to select an object which is having the required property (or metric).

My sample group containing both, VMs and Datastores has the following membership criteria configuration.C

And automatically contains my two objects.

The members of the group now receive the new policy with disabled alert definitions.

To remove objects from the new custom group and let them receive the old policy, we simply set the vCenter attribute to no.

As already mentioned in Part 2 of this blog series, it may take up to 20 minutes until the membership has be re-evaluated and the objects have been removed from the group.

vSphere Tags

In contrast to vCenter Custom Attributes vSphere Tags are easy to use in vCenter, assigning tags to multiple objects can be done in the UI with few clicks.

This is a simple tag to categorize objects in maintenance.

Again, the next vROps collection cycle needs to complete to collect the new value.

The corresponding property is vROps differs from the property reflecting vCenter Custom Attributes. There is only one property called “vSphere Tag” and the value of this property contains all tags assigned to the particular object, following the format:

[<CategoryX-TagX>,<CategoryY-TagY>,…]

That means, that we need to use the “contains” operator in the membership criteria instead of “is” as for custom attributes. That also means, that you need to be carful with naming your tags to avoid overlaps which may result in unwanted behavior of you group membership criteria.

As expected, the group contains three objects which got the maintenance vSphere Tag assigned.

As with custom attributes, remove the tag after the maintenance has been completed, wait few minutes and the objects leave the custom group automatically.

This is the last part of the “Maintenance Mode for vRealize Operations Objects” blog series.

I wish you and your loved ones a a healthy start into the New Year 2020.