VMware vROPs custom resourceIdentifiers API Error 1501 with Nagini.py

When pushing custom resource kinds using the vROPs Python nagini client’s find_create_resource_push_data() method, and you include custom resourceIdentifiers, you might get an error:

You can fix this by creating your own version of the find_create_resource_push_data() and find_create_resource_with_adapter_key() methods.  You need to handle the API exception, and treat the error condition as if your call to find the resource succeeded but returned no results.

This code is just an incomplete example.

vROPs Python Client and Unexpected “Resource not found”

Using the vRealize Operations Manager 6.6 Python nagini client (version 1.0), I encountered an interesting unexpected result when using the client to push custom metrics to vROPs.  For context, see this blog post on creating a custom metric adapter for vROPs.

This error occurred when pushing resource metrics to vROPS:

In particular, last line indicates the vROPS API returned an error “resource… already exists”, which means the nagini client is attempting to create the resource:

The method find_create_resource_push_data() is supposed to find existing resources and not attempt to recreate them. So what is going wrong?

To figure this out, I followed my normal debugging procedure of breaking this down into smaller parts. Reading through the nagini client Python code, the nagini client makes a call to get_resources_with_adapter_and_resource_kind() and parses the results to determine if the resource already exists.

So, I ran just that method with my specific parameters, and to my unfortunate surprise received two results back – two resources were found. However the method find_create_resource_with_adapter_key() expects only a single result, otherwise it goes into its “create resource” mode. A more helpful error message here would be great and easy to add, something like “if len(results) > 1 throw an error that you have too many resource hits.” Oh well.

From the API documentation page for the underlying method, getResourcesWithAdapterandResourceKind, I identified the root cause:

Query for Resources within a particular Adapter Kind and Resource Kind.
Optionally filter these resources based on resource name. The resource name (specified as a query parameter) will be used for doing a partial match.

In my case, the specific resource name is also a subset of another resource name.  Hence the bug.

Without any way to control partial vs. exact match in the API currently, my two options are to re-implement this portion of the nagini client logic and do the exact name match filtering in Python, or to use the richer resource identifier method which allows specifying multiple keys for a resource to help identify it with more than simple name matching.

Hope this helps.


Packet Capture on ESXi, pktcap-uw Helper Script

By now, pktcap-uw, the VMware tool to run flexible packet captures on ESXi hosts, including capturing VM vnic traffic, is old news.  It’s great, but when I need to use it, I always have to take a minute to remember syntax and method.  I’d rather spend my mental energy troubleshooting the networking issue that necessitated the packet capture in the first place.

So, I wrote a small helper script that enables this simple syntax:

It generates three pcap files, for input, output, and drops.  Get the script and instructions here:


Understanding vRealize Log Insight Event Forwarding Filters Behavior

vRealize Log Insight enables generic event forwarding via the syslog protocol.  The Event Forwarding filters, at least to me, were initially not the most intuitive.  So, here’s what I’ve learned using vRLI 4.5.

Understanding Implicit Conditional Operators

First, notice the gap between *Key1* and *Key2*.  That indicates they are two separate criteria (values) that will satisfy the filter rule.  Filter rules evaluate true when ANY value for a specific filter rule meets the criteria.  So, there is an implicit OR between all the values for a particular rule.

Second, filter rules are additive.  There is an implicit AND between all the filter rules assigned to an Event Forwarding Destination.

“Not Match” Adds Complexity

Consider these two equivalent scenarios:

  • Scenario 1
    • text does not match *Key1*
    • text does not match *Key4*

There is an implicit AND between the two filters.  So messages will not be forwarded if they contain either Key1 or Key4.  Think of it as !(match *Key1*) AND !(match *Key4*).

  • Scenario 2
    • text does not match *Key1* *Key4*

Think of this as not (match *Key1* OR match *Key4*).  If the message contains Key1 or Key4, it will match the parenthesized condition, then the negation is applied.  Net result, a message containing any of the “not match” values.


I recorded actual test results, by crafting sample syslog messages using a generator pointed to Log Insight, and configuring an Event Forwarder using the following filters.  I observed the results with a generic syslog-ng instance configured to receive the forwarded events from Log Insight.

Because of its importance, I denoted where multiple values to a filter are separated by pressing [Enter] after typing each value.  If you just separate the values by a space, you will end up with a single value like “Key1 Key2” instead of “Key1”, “Key2”.  This is easy (for me) to mistype, so here’s one last screenshot to remind you:

Showing multiple separate values that have an implicit OR (*Key1* OR *Key2*).

Finally, here are my test results for reference:

Filters Results Analysis
hostname matches host1
hostname matches host2
no msgs forwarded filter1 AND filter2
hostname matches host1[Enter] host2[Enter] all msgs forwarded value1 OR value2
text matches Key1 no msgs forwarded entire text must match "Key1"!
text matches *Key1* msgs with Key1 forwarded
text matches *Key1*[Enter] *Key4*[Enter] all messages forwarded value1 OR value2
text matches *Key1*
text does not match *Key4*
msgs with Key1 and not Key4 (match value1) AND !(match value2)

Hope this helps.

vRealize Operations Manager 6.x UI issues with Touch Screen

UPDATE: If you are running vROPs 6.6.1, you can install this .pak file to resolve the touch screen issue.

If you have a touch-screen system and are using vROPs 6.x, you’re in for a bad time.  There is a KB about this:

Resolution is disable the touch screen device.

Go to Device Manager -> Human Interface Devices -> Disable device

Some of the symptoms I experienced:

  • Clicking the User icon and About did not open the About screen
  • Setting a filter type on Reports screen would reload the Home screen
  • Could not create a new vROPs View – UI crashes after configuring Subjects
  • Observed the following error in the Chrome dev console

I am simply leaving this here in case someone else, like me, searches for the browser client side error message.

Recent Posts



GiottoPress by Enrique Chavez