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 surfaceWhere it lives in 9.1GrammarLineage
Networks entity searchInside 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 pageMetric of Object Type where ... childOf ...vROps / Aria Operations
Log searchOperate > LogsLog filtering, alert queries, field extractionAria Operations for Logs
Custom Query (new in 9.1)Operate > Real-Time Metrics / Troubleshooting WorkbenchPromQLNew 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:

OperatorExample
= / !=flows where source ip address = '10.16.240.0/24'
> < >= <=vms where memory >= 4096 mb, vms where cpu usage rate < 70%
like / not likevms where name like 'app'
in / not inflows where port in (22, 23, 80, 443)
is set / is not setvms where firewall rule is set
matches / not matchesvm 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).

Saved Searches and the Widget Trick

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 answersQuery
Denied flows, environment-wideflows where firewall action = deny
Internet traffic by source VMsum(bytes) of flows where Flow Type = 'Internet' group by src vm
Top talkers, limit 10sum(bytes) of flows group by src vm order by sum(bytes) limit 10
Top ports by volumesum(bytes) of flow group by port order by sum(bytes)
Sum and average per portsum(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 candidatestop 7 flow where Flow Type = 'Switched' group by Subnet Network order by sum(Bytes) in last 7 days
VMs talking outside the countrytop 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 directionFlows where (src tier = 'App' and destination Tier = 'DB') OR (destination tier = 'App' and source tier = 'DB')
Data center interconnect traffic between two sitessum(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 answersQuery
Effective rules between two VMsfirewall rules from 'Prod-Midtier-1' to 'Prod-Db-1'
Any/any allow rules — segmentation debtfirewall rule where action = allow and service any = true
Masked (shadowed) rulesFirewall Rule Masked Alert
Rules created recentlyNew firewall rules in last 24 hours
Rules no flow has ever hitFirewall rule where flow is not set
Flow count per ruleFlow group by firewall rule
Flows hitting specific rule IDsFlow where rule id in (1011, 1012, 1013)
VMs excluded from the DFWvm where firewall status = 'Excluded'
VMs covered by a given rulevm where Firewall Rule = 'Prod MidTier to Prod DB - DBService'
Security groups referenced by no rule at allSecurity 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 churnfirewall rule membership change, security group membership change

VM and Host Inventory

What it answersQuery
VM count per OSvms group by operating system
Segments with the most VMsvm group by l2 network
Datastores with the most VMsvm group by datastore
Hosts per vSphere version / buildhost group by version, host group by OS
Network identity card for every VMl2 network, vlan, ip address, default gateway of vms
VMs still running vulnerable operating systemscount 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 lineCPU Usage Rate, Network Rate, Memory Usage Rate, mac address, ip, vxlan, host of vm 'Quality control-VM26'

Physical Network and Routing

What it answersQuery
All switches from one vendorswitches where vendor = Cisco
Switch ports dropping packets, worst firstswitchport where vendor = 'Cisco' order by total packet drops
Routes in a VRFroutes where vrf = 'Provider Edge 3'
Routes via a given next hoproutes where NextHop Router = 'California-Edge'
BGP sessions that are not upBGP Connection where BGP Status != 'ACTIVE'
BGP neighbors of a routerlist(BGP Neighbor) of NSX-T Router 'Router Name'
ECMP-enabled routers on a managerNSX-T Router where ECMP = 'Enabled' and manager = 'NSX-T Manager Name'

Kubernetes (VKS / Antrea)

What it answersQuery
Pod distribution per nodekubernetes Pods group by Kubernetes Node
Nodes not in Ready statekubernetes nodes where Ready != 'True'
Pods created in the last hournew kubernetes pod in last 1 hour
Dropped flows per serviceflows where firewall action = 'DROP' group by Kubernetes Service
Cross-namespace compliance checkflows 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.

References