VCF Operations for Networks 9.1 Search Queries: The vRNI Query Language Lives On

Cosmin Trif — Mon, 27 Jul 2026 07:00:00 +0000

If you spent years typing flows where firewall action = deny into vRealize Network Insight, then watched the product get renamed to Aria Operations for Networks and then absorbed into VCF Operations as VCF Operations for Networks, you probably have one practical question: did the search language survive?

It did — completely. I compared the VCF Operations for Networks 9.1 search documentation against the legacy Aria Operations for Networks 6.13 docs page by page, and the query grammar is identical: same entity types, same where operators, same group by / order by / limit clauses, same planning and path queries. Even the REST API still answers under the old /api/ni/ (Network Insight) namespace. Your saved searches and your muscle memory carry over as-is.

The short version:

VCF Operations 9.1 has one console but at least four separate query languages: the networks entity search (vRNI heritage), the Enhanced Search metric queries (vROps heritage), log search under Operate > Logs, and the new-in-9.1 PromQL Custom Query for real-time metrics. Knowing which bar you are typing into matters more than any syntax detail.
The networks search DSL is unchanged from vRNI/AON: <projection> of <entity> where <condition> group by <property> order by <field> limit N, plus top N, in last N days, path queries (VM 'a' to VM 'b'), and plan queries for micro-segmentation.
The 9.1 differences are cosmetic or peripheral: NSX Advanced Load Balancer is renamed Avi Load Balancer in the docs, “VMware Cloud (VMC)” prose became “VMware Cloud on AWS”, the VMware SD-WAN (VeloCloud) search-queries page is gone from the 9.1 doc tree, and AWS/Azure data sources are deprecated in 9.1.
The classic community query lists — the ones we all bookmarked in the vRNI days — still apply. I have collected the best of them below, together with the official examples, into one cookbook.

Everything here is based on the 9.1 documentation set and verified against the legacy 6.13 docs; sources are linked at the end.

One Console, Four Query Languages

The single most confusing thing about search in VCF Operations 9.1 is that “search” is not one feature. The console consolidates products that each brought their own query engine, and none of them were merged:

Query surface	Where it lives in 9.1	Grammar	Lineage
Networks entity search	Inside the VCF Operations for Networks section (Operate pillar)	`entity where ... group by ...`	vRNI / Aria Operations for Networks
Enhanced Search (metric queries)	The global search bar in the top menu, on every page	`Metric of Object Type where ... childOf ...`	vROps / Aria Operations
Log search	Operate > Logs	Log filtering, alert queries, field extraction	Aria Operations for Logs
Custom Query (new in 9.1)	Operate > Real-Time Metrics / Troubleshooting Workbench	PromQL	New real-time metrics pipeline

This post is mainly about the first one, because that is where the network troubleshooting value is. The second gets its own section further down, since the two are easy to conflate — the same word where appears in both grammars but the operator sets are different. The 9.1 release notes only call out one genuinely new query mechanism, and it is the fourth: “Use PromQL-based search queries to derive operational insights.” Neither the networks DSL nor the Enhanced Search grammar changed in 9.1.

A note on architecture, since the rebrand hides it: VCF Operations for Networks is still a separate, pre-hardened appliance, deployed as a Day-2 operation from VCF Operations and lifecycle-managed by Fleet Management — not code merged into the core VCF Operations binary. Only one instance can be integrated per fleet. Licensing is automatic starting with VCF 9: the component is licensed through the vCenter instance it is connected to, and there is nothing to license manually anymore.

Anatomy of a Networks Search Query

The documentation splits queries into four categories: structured queries, entity queries, planning queries, and path queries. In practice you will spend most of your time on structured queries, which read like a relaxed SQL:

sum(bytes) of flows where Flow Type = 'Routed' group by Source Subnet Network order by sum(bytes)

The pieces, in the order the parser expects them:

Entity Type (Mandatory)

Every structured query is anchored on an entity type: vms, hosts, flows, firewall rules, switch ports, routes, nsx managers, kubernetes pods, and many more. Singular and plural both work, and synonyms are accepted (virtual machine = vm). Queries are not case-sensitive.

Typing just the entity type is already a valid query — vms lists every VM. The search bar validates as you type: a check mark means the query is valid, a cross means it is not. An old vRNI trick from the community lists that is still worth trying: type help into the search field to bring up the search help.

Filters: `where` Plus Operators

Conditions are property, operator, value, combined with and / or and parentheses:

Operator	Example
`=` / `!=`	`flows where source ip address = '10.16.240.0/24'`
`>` `<` `>=` `<=`	`vms where memory >= 4096 mb`, `vms where cpu usage rate < 70%`
`like` / `not like`	`vms where name like 'app'`
`in` / `not in`	`flows where port in (22, 23, 80, 443)`
`is set` / `is not set`	`vms where firewall rule is set`
`matches` / `not matches`	`vm where name matches '[a-z]vm-delta[0-9]'` (regex)
grouping `()`	`flows where (src tier = 'App' and destination tier = 'DB') OR (destination tier = 'App' and source tier = 'DB')`

The underrated one is the nested in — a sub-query as the right-hand side:

vm where host in (host where Blade like 'sys/chassis-1')
vm where vlan in (vlan of vm where os in ('Microsoft Windows Server 2003', 'Microsoft Windows Server 2008'))

The second example is a trimmed version of the documented “total attack surface” query (the full one lists five vulnerable operating systems and ends with group by Vlan): every VM that shares a VLAN with a VM running a vulnerable OS.

Projections: What to Show

By default a query returns the entity’s standard field set. A projection in front changes that:

Property list: os of vms, cpu cores of vms, or several at once — CPU Usage Rate, Network Rate, mac address, ip, host of vm 'Quality control-VM26'
Count: count of vms, count of vm where operating system like 'Microsoft Windows Server 2008'
List(): fetch one entity while filtering on another — List(host) of vms where memory <= 2gb
Aggregates (sum, max, min, avg): sum(memory) of hosts, sum(bytes) of flows
Series for time-series graphs: series(avg(cpu usage)) of vms where cpu cores = 4

Grouping, Ordering, Limiting

vms group by host
sum(bytes) of flows group by dest vm order by sum(bytes)
vms order by memory limit 5

Three rules worth memorizing, because they are the usual cause of the red X:

limit must be preceded by order by.
order by accepts exactly one field; descending is the default (asc flips it).
When a group by query has a projection or an order by, the projection must contain an aggregation function. sum(bytes) of flows group by dest vm is valid; bytes of flows group by dest vm is explicitly called out in the docs as invalid.

Time: `top N` and `in last N days`

The examples in the official advanced-queries page lean heavily on two inline constructs:

top 7 vm group by name, Vlan order by sum(Total Network Traffic) in last 7 days
Kubernetes alerts where alert code = 'ImagePullBackOff' in last 24 hours
New firewall rules in last 24 hours

There is also a UI time control next to the search bar with presets (“last 24 hours”, “last 3 days”), an At option for a point in time, and a Between option for a range — useful for re-running the same query against last Tuesday’s state, which remains one of this product’s superpowers.

Path and Planning Queries

Path queries draw the hop-by-hop topology between two endpoints, including the underlay:

VMware VM 'VM01' to VMware VM 'VM02'
vm 'app1-web' to Internet

Planning queries feed the micro-segmentation donut — the flow analysis view you use before writing distributed-firewall rules. The documented forms take a bare argument:

plan security in last 7 days
plan securitygroup1
plan host1

The community lists extend these with filters — plan vm where folder = 'Production' and plan flows where vm = 'app1-web' and traffic type = 'INTERNET_TRAFFIC' both come from mtellin’s gist rather than the official grammar reference, but they follow the same where rules as everything else.

Entity and Free-Text Searches

Plain strings work too: 'prod-68-1' (exact name, quoted), prod (partial name), vm app1 (entity type plus partial name). And a community favorite from the gist: paste a bare MAC address like 00:50:56:a6:c9:6a into the search bar to find the machine that owns it — a great party trick when someone shows up with nothing but a switch log.

vCenter Tags

vm where tag = 'Environment:Production'

The syntax is '{category}:{tagname}'. Tags are also available as a Group-by criterion in flow analysis (up to three at once).

The bookmark icon next to the search bar saves any valid query; saved searches are per-user, and six defaults ship with the product (All Flows, Applications, Azure, Kubernetes Dashboard, Top Trends, NSX). Two features worth more attention than they get:

Help > Useful Searches is a curated, tagged library of pre-built queries — parameterized ones open pre-filled with sample values you swap out.
View Search Query on dashboard widgets (VM Details, Host Details, NSX Manager, Flow Insights, and a few others) reveals the query powering the widget, which you can copy into the search bar and modify. This is the fastest way I know to learn the DSL: find a widget that almost shows what you want, steal its query, adjust.

And almost any search can become an alert: run the query, then create a notification from the results page. Threshold queries (flows where firewall action = deny, packet-drop queries) make surprisingly good custom alerts.

The Query Cookbook

The queries below are collected from the official 9.1 search-queries reference and the two classic community lists — Pat’s vRNI search queries post and mtellin’s gist — deduplicated and grouped by what I actually use them for. Since the grammar is unchanged from vRNI, the community-era queries remain valid in 9.1 unless they depend on a data source that is gone (more on that below).

Flows and Traffic Patterns

What it answers	Query
Denied flows, environment-wide	`flows where firewall action = deny`
Internet traffic by source VM	`sum(bytes) of flows where Flow Type = 'Internet' group by src vm`
Top talkers, limit 10	`sum(bytes) of flows group by src vm order by sum(bytes) limit 10`
Top ports by volume	`sum(bytes) of flow group by port order by sum(bytes)`
Sum and average per port	`sum(bytes), avg(bytes) of flows group by port`
Top routed subnet pairs (last 7 days)	`top 7 flow where Flow Type = 'Routed' group by Source Subnet Network, Destination Subnet Network order by sum(Bytes) in last 7 days`
Traffic that never leaves its subnet — micro-segmentation candidates	`top 7 flow where Flow Type = 'Switched' group by Subnet Network order by sum(Bytes) in last 7 days`
VMs talking outside the country	`top 7 flow where Destination Country != 'United States' group by Source VM, Destination Country order by sum(Bytes) in last 7 days`
Traffic between two application tiers, either direction	`Flows where (src tier = 'App' and destination Tier = 'DB') OR (destination tier = 'App' and source tier = 'DB')`
Data center interconnect traffic between two sites	`sum(bytes) of flows where (Dst Manager = 'site2' AND src manager = 'site1') OR (Dst Manager = 'site1' AND src manager = 'site2')`

NSX Firewall and Security

What it answers	Query
Effective rules between two VMs	`firewall rules from 'Prod-Midtier-1' to 'Prod-Db-1'`
Any/any allow rules — segmentation debt	`firewall rule where action = allow and service any = true`
Masked (shadowed) rules	`Firewall Rule Masked Alert`
Rules created recently	`New firewall rules in last 24 hours`
Rules no flow has ever hit	`Firewall rule where flow is not set`
Flow count per rule	`Flow group by firewall rule`
Flows hitting specific rule IDs	`Flow where rule id in (1011, 1012, 1013)`
VMs excluded from the DFW	`vm where firewall status = 'Excluded'`
VMs covered by a given rule	`vm where Firewall Rule = 'Prod MidTier to Prod DB - DBService'`
Security groups referenced by no rule at all	`Security group where Indirect Incoming Rules is not set and Indirect Outgoing Rules is not set and Direct Incoming Rules is not set and Direct Outgoing Rules is not set`
Rule and group membership churn	`firewall rule membership change`, `security group membership change`

VM and Host Inventory

What it answers	Query
VM count per OS	`vms group by operating system`
Segments with the most VMs	`vm group by l2 network`
Datastores with the most VMs	`vm group by datastore`
Hosts per vSphere version / build	`host group by version`, `host group by OS`
Network identity card for every VM	`l2 network, vlan, ip address, default gateway of vms`
VMs still running vulnerable operating systems	`count of vm where Operating System like 'Microsoft Windows Server 2003' or Operating System like 'Microsoft Windows Server 2008'`
Everything about one VM in a single line	`CPU Usage Rate, Network Rate, Memory Usage Rate, mac address, ip, vxlan, host of vm 'Quality control-VM26'`

Physical Network and Routing

What it answers	Query
All switches from one vendor	`switches where vendor = Cisco`
Switch ports dropping packets, worst first	`switchport where vendor = 'Cisco' order by total packet drops`
Routes in a VRF	`routes where vrf = 'Provider Edge 3'`
Routes via a given next hop	`routes where NextHop Router = 'California-Edge'`
BGP sessions that are not up	`BGP Connection where BGP Status != 'ACTIVE'`
BGP neighbors of a router	`list(BGP Neighbor) of NSX-T Router 'Router Name'`
ECMP-enabled routers on a manager	`NSX-T Router where ECMP = 'Enabled' and manager = 'NSX-T Manager Name'`

Kubernetes (VKS / Antrea)

What it answers	Query
Pod distribution per node	`kubernetes Pods group by Kubernetes Node`
Nodes not in Ready state	`kubernetes nodes where Ready != 'True'`
Pods created in the last hour	`new kubernetes pod in last 1 hour`
Dropped flows per service	`flows where firewall action = 'DROP' group by Kubernetes Service`
Cross-namespace compliance check	`flows from Kubernetes Namespace 'PCI' to Kubernetes Namespace 'Non-PCI'`

This category got more relevant in 9.1: container IPFIX flows from VKS clusters running Antrea now export to the VCF Operations for Networks collector, with pod-to-pod and pod-to-external traffic dashboards.

Dashboard Shortcuts

Not structured queries, but single keywords from the gist that jump straight to built-in views: problem, change (recent changes in the environment), topn, storage, and pci compliance of VC Manager '192.168.10.10' (the PCI dashboard — which, per the gist, required an Enterprise license back in the vRNI days).

A Caveat on Community Shorthand

The community lists include a few compact forms you will not find in the official grammar reference — vm by VLAN, show VLAN, vm by network rate, top 10 vms by max packet drops, flows where flow type = 'VM-Physical' by bytes. They come from vRNI-era posts that predate the current documented grammar, which only uses group by / order by for these jobs. I have kept them out of the tables above for that reason. If you rely on one of them, the in-product validation check mark will tell you immediately whether your build still accepts it.

The Other Search Bar: Enhanced Search Metric Queries

The global search bar at the top of the VCF Operations console — the one that is on every page — is a different animal with its own documented query language, under the section Broadcom titles “Enhanced Search Capability”. It searches the vROps-side world: objects, metrics, properties, dashboards, reports, views, alert definitions, symptom definitions, recommendations, notifications, IP addresses, super metrics, and (since recent releases) features — type li and select Feature to jump straight to Licenses, navigation path included.

Its metric query grammar looks like this:

CPU|Usage % of Virtual Machine
CPU|Usage % of Virtual Machine where CPU|Usage % > 15 and Memory|Usage % > 15
CPU|Demand MHz of Virtual Machine where Configuration|Name contains 'Centos'
CPU|Usage % of Virtual Machine where CPU|Usage % > 15 or Memory|Usage % > 15 childOf vSphere World

The differences from the networks DSL are exactly where you would trip:

The pattern is Metric of Object Type, with the pipe character separating metric group and metric name (CPU|Usage %). If you start with a metric name, naming the object type is mandatory.
String operators are camelCase keywords: equals, notEquals, contains, notContains, startsWith, notStartsWith — there is no like, no in, no matches here. Numeric operators (>, >=, <, <=, =, !=) plus arithmetic (+ - * / with parentheses) and and/or round out the set. String values are case-insensitive.
childOf at the end of the query scopes results to descendants of an ancestor object — the closest thing this grammar has to the networks DSL’s nested in.
Hard limits: 300 characters per query, at most five different metric names. Break either and a red banner explains the issue; for syntax errors specifically it reads “The query contains syntax error(s). Please modify it to get suggestions.”
There is no group by or order by in the query itself; slicing happens on the Metric Search Results page instead, via Transformation (Min/Max/Average/Sum/First/Last/Current), Roll Up (hour through year), Parents, value-distribution buckets, and time settings. The Transformation filter only activates when the query has a where condition and the object type has at most 200 objects over at most one month. From any result row, the vertical-ellipsis menu jumps into the Troubleshooting Workbench.

One honest note: none of this is new in 9.1. I compared the 9.0 and 9.1 pages — the content is identical — and the same grammar exists in Aria Operations 8.x. What is new in 9.1 on the metrics side is the PromQL-based Custom Query in Real-Time Metrics, which is a separate topic (and a separate language) altogether.

What Actually Changed in 9.1 for Operations for Networks

Since search itself did not move, here is what did — the 9.1 items relevant to a networks operator, from the release notes and product support notes:

Network Assessment and Value report — evaluates your current VDS-based networking and produces a CAPEX/OPEX analysis for VCF networking capabilities. It replaces the vCenter Assessment report, which was removed.
VPC Planning — guided vSphere-to-VPC transition planning, with subnet tables and a CSV export of the generated VPC design.
Expanded IPFIX for VKS clusters — Antrea container flows land in the collector; pod-to-pod and pod-to-external dashboards.
Expanded migration planning — automatic migration wave generation, clustering workloads by flow, latency, and bandwidth data.
Network health dashboards — NSX Edge appliance and ESX host networking capacity monitoring surfaced through VCF Operations Health and Diagnostics.
Deprecations: AWS and Azure data sources are deprecated in 9.1, and the networks API had 22 operations marked deprecated — the largest deprecation set in the Operations component. The VMware SD-WAN (VeloCloud) search-queries reference page is also absent from the 9.1 documentation tree.

That deprecation list is worth acting on if you have search-based alerting or scripts built on AWS/Azure entity queries (AWS EC2 where Security Group = ..., Azure NSG Rule where Action = 'ALLOW') — the syntax still exists in the 9.1 reference today, but the data sources feeding those entities are on the way out.

Getting There from Standalone 6.x

If you are still on a standalone appliance — I have covered upgrading Aria Operations for Networks to 6.14 via the upgrade bundle and via Aria Suite Lifecycle before — the path into 9.x is: get to 6.14.0 Patch 6 or 6.14.1+, import the instance into VCF Operations Fleet Management, upgrade it in place to VCF Operations for Networks 9.0.x, and from there directly to 9.1. Only one instance can be imported per fleet. Every search query in this post works the same on both sides of that migration, which is precisely the point.

The API Corner

For automation, the search subsystem is exposed over REST, still under the Network Insight namespace:

POST /api/ni/search/ql — takes the same query-language strings you type in the search bar
POST /api/ni/search — entity search
POST /api/ni/search/aggregation — aggregations
POST /api/ni/search/groupby — group-by queries

The schemas are on the VCF Operations for Networks API reference. The ql endpoint is the interesting one: anything you prototype in the search bar can be lifted verbatim into a script.

Search Queries on Cosmin.us

VCF Operations for Networks 9.1 Search Queries: The vRNI Query Language Lives On

One Console, Four Query Languages

Anatomy of a Networks Search Query

Entity Type (Mandatory)

Filters: `where` Plus Operators

Projections: What to Show

Grouping, Ordering, Limiting

Time: `top N` and `in last N days`

Path and Planning Queries

Entity and Free-Text Searches

vCenter Tags

Saved Searches and the Widget Trick

The Query Cookbook

Flows and Traffic Patterns

NSX Firewall and Security

VM and Host Inventory

Physical Network and Routing

Kubernetes (VKS / Antrea)

Dashboard Shortcuts

A Caveat on Community Shorthand

The Other Search Bar: Enhanced Search Metric Queries

What Actually Changed in 9.1 for Operations for Networks

Getting There from Standalone 6.x

The API Corner

References

Search Queries on Cosmin.us

VCF Operations for Networks 9.1 Search Queries: The vRNI Query Language Lives On

One Console, Four Query Languages

Anatomy of a Networks Search Query

Entity Type (Mandatory)

Filters: where Plus Operators

Projections: What to Show

Grouping, Ordering, Limiting

Time: top N and in last N days

Path and Planning Queries

Entity and Free-Text Searches

vCenter Tags

Saved Searches and the Widget Trick

The Query Cookbook

Flows and Traffic Patterns

NSX Firewall and Security

VM and Host Inventory

Physical Network and Routing

Kubernetes (VKS / Antrea)

Dashboard Shortcuts

A Caveat on Community Shorthand

The Other Search Bar: Enhanced Search Metric Queries

What Actually Changed in 9.1 for Operations for Networks

Getting There from Standalone 6.x

The API Corner

References

Filters: `where` Plus Operators

Time: `top N` and `in last N days`