We're reclaiming inactive PDIs to keep them available for active builders. Learn what's changing, who's affected, and how to protect your work. Read More

Traffic-Based Service Mapping for vCenter / ESX Hosts — Has Anyone Done This Successfully?

Ashutosh32
Tera Contributor

Monday

Hi Community,

We are currently working on building Service Maps for our Hypervisor infrastructure (ESX hosts and VMs) in ServiceNow and have hit a wall — hoping someone here has been down this path before.

Our Setup:

  • We have an active vCenter integration in ServiceNow that is successfully bringing in all vCenter instances and everything below them — ESX hosts, VMs, and their relationships — into CMDB
  • We are trying to build a traffic-based top-down Service Map starting from vCenter or the ESX hosts

What We Have Tried:

  • Created entry points using individual ESX host IPs — resulted in SN-1000 (All patterns failed) and SN-1001 (No pattern found for entry point type) errors
  • Confirmed with ServiceNow support that ESX hosts do not run discoverable applications or processes, making traffic-based mapping not possible for ESX directly
  • Explored tag-based mapping but were advised it could lead to a dead block

Our Question: Has anyone successfully done traffic-based Service Mapping for vCenter or ESX infrastructure where vCenter integration is already in place? Specifically:

  • Did you use vCenter itself as the entry point and if so, what entry point type and configuration worked?
  • Were you able to get the ESX hosts and VMs to appear in the service map automatically as child objects
  • Any other approach that worked for mapping hypervisor infrastructure beyond manual mapping or dependency/unified maps?

    Any guidance, experience, or pointers to relevant documentation would be greatly appreciated!

    Thanks in advance.

0 Helpfuls
  • 109 Views
1 REPLY 1

Vikram Reddy
Tera Guru

yesterday

Hello @Ashutosh32,

 

VM (cmdb_ci_vm_instance)
  Virtualized by / Virtualizes  -->  ESXi Host (cmdb_ci_esx_server)
  Runs on / Hosts                -->  Cluster (cmdb_ci_cluster_resource)
  Managed by / Manages           -->  vCenter (cmdb_ci_vcenter)

Stop pointing top-down entry points at vCenter or the ESX hosts, that's the wall you're hitting. An entry point in Service Mapping has to be a URL, TCP port, or DB connection string, basically something with a listening application-layer process the identification section can pattern-match against. The hypervisor management stack is API-driven, not process-driven, there's nothing listening on the ESX host itself for a pattern to identify, which is exactly why you get SN-1000 and SN-1001. ServiceNow support told you correctly: it isn't a config problem, it's architecturally not a valid entry point type.

The part worth knowing is you don't need vCenter or ESX as a separate entry point at all. Your vCenter integration is already writing the relationship chain above into cmdb_rel_ci (that Virtualized by::Virtualizes relationship is a documented CI relationship type). So build your top-down maps from the actual workloads:

  • URL entry points for web apps running on the VMs
  • TCP entry points for backend/middleware services on the VMs
  • DB connection string entry points for databases on the VMs

Once Service Mapping traces the app down to a host and identifies that host as a VM, the hypervisor chain (ESXi host, cluster, vCenter) surfaces underneath automatically using relationships already in the CMDB, no traffic tracing needed for that layer because there's no traffic to trace.

For a pure infrastructure-only view where you genuinely want vCenter down to VMs with no application in the picture, that's what the Unified Map in the Service Mapping Workspace is for (enable sn_sm_scoped_app.sa.unified_map.enabled). It renders the same cmdb_rel_ci data your discovery already collected, combined with any traffic or tag data you have, instead of depending on pattern-based tracing that layer was never designed to support. That's the intended tool here, not a fallback, and it lines up with what you were told about tag-based entry points hitting a dead end: tags identify a resource, they don't give the identification engine a listening service to key a pattern off.

References

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls