ServiceNow Discovery — Troubleshooting for VMware ESX / vCenter Discovery - Support and Troubleshooting

ServiceNow Discovery — Troubleshooting for VMware ESX / vCenter Discovery Summary .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } ServiceNow Discovery — Troubleshooting Guide VMware ESX / vCenter Discovery Complete reference: credential setup, probe chain, CI hierarchy, properties, error codes & known issues Protocol: HTTP + SOAP CI Type: cmdb_ci_esx_server Target: vCenter IP (not ESX directly) Versions: Zurich / Xanadu Contents Overview & Architecture Pre-Discovery Checklist Troubleshoot by Symptom Error Message Reference System Properties Reference Probe/Sensor Chain Deep Dive Known Issues & Limitations 1. Overview & Architecture Critical: Target vCenter — not ESX hosts Unlike Network Switch or Router Discovery which targets device IPs directly, VMware Discovery must target the vCenter Server IP . Discovery authenticates to vCenter via its SOAP/REST API (port 443) and retrieves the complete inventory tree — datacenters, clusters, ESX hosts, and all VMs — in a single orchestrated probe chain. Pointing Discovery at individual ESX host IPs discovers only basic IP/host info with no relationships. ServiceNow Discovery uses the standard 4-phase engine for VMware, but the technology in Phase 4 is different from SNMP-based patterns. Instead of a Pattern (.sa_pattern), it uses a legacy Probe/Sensor chain that calls the VMware vSphere Web Services (SOAP) API.

Phase Mechanism What happens for VMware 1 — Scanning Shazzam + port probe Port probe hits vCenter IP on TCP 443 / 5480 / 9443. Shazzam confirms host is up. 2 — Classification Process/port classifier Port 5480 (VAMI) or process vmware-vpxd identifies the host as cmdb_ci_vcenter . 3 — Identification IRE (for vCenter CI only) IRE creates/updates the cmdb_ci_vcenter record. ESX hosts are identified separately by VCenterESXHostsSensor — not IRE. 4 — Exploration Probe/Sensor chain (SOAP) Full vCenter inventory walk via SOAP API: datacenters, clusters, ESX hosts, VMs, networks, datastores, folders. How VMware Discovery differs from Switch/Router Discovery

Dimension Network Switch/Router VMware ESX/vCenter Target IP Device IP directly vCenter IP only — never ESX IPs Protocol SNMP (UDP 161) HTTPS + SOAP (TCP 443) Credential type SNMP (v2c/v3) VMware (not SSH/SNMP/WMI) Exploration engine Pattern (sa_pattern) Probe/Sensor chain ESX identification IRE (CIIdentification) VCenterESXHostsSensor (bypasses IRE) CIs created 1 CI + network adapters 10+ CI types across full inventory All CI types created by vCenter Discovery

CI Table Represents Created by cmdb_ci_vcenter vCenter Server IRE (Phase 3) cmdb_ci_esx_server ESX/ESXi Host VCenterESXHostsSensor cmdb_ci_vmware_instance VM (vCenter metadata) VCenterVMsSensor cmdb_ci_linux_server cmdb_ci_win_server VM Guest OS Separate IP-based discovery of VM's IP cmdb_ci_vmware_datacenter vSphere Datacenter VCenterDatacenterSensor cmdb_ci_vcenter_cluster vSphere Cluster VCenterClustersSensor cmdb_ci_vcenter_network vSphere Port Group / Network VCenterNetworkSensor cmdb_ci_vcenter_datastore vSphere Datastore (storage) VCenterDatastoresSensor cmdb_ci_vcenter_folder vSphere Folder VCenterFoldersSensor cmdb_ci_vmware_template VM Template VCenterVMsSensor (template=true rows) Key fields on cmdb_ci_esx_server (VMware-specific)

Field VMware API Source Purpose / Notes morid _moref.value Managed Object Reference ID. vCenter-internal identifier. Changes if ESXi is removed and re-added to vCenter. vcenter_ref vCenter sys_id Reference to the parent cmdb_ci_vcenter CI. Use to see which vCenter manages this host. vcenter_uuid hardware.systemInfo.uuid Primary identifier key. This is the hardware UUID of the ESX host. Critical for deduplication. Also stored as correlation_id in some versions. cluster_id ClusterComputeResource MoRef Identifies which vSphere cluster this ESX host belongs to. connection_state summary.runtime.connectionState Values: connected / disconnected / notResponding. Disconnected hosts are still reported by vCenter. power_state summary.runtime.powerState poweredOn / poweredOff / standBy / unknown. hyper_threading config.hyperThread.active Boolean. True if HyperThreading is enabled on this host. logical_processor hardware.cpuInfo.numCpuThreads Total logical processors (cores × threads per core when HT enabled). object_id hardware.systemInfo.uuid Used as a secondary identifier. Populated from the ESX hardware UUID. Differs from morid. Relationship types created by vCenter Discovery

Relationship type Parent CI Child CI Created by Virtualized by::Virtualizes cmdb_ci_esx_server cmdb_ci_linux/win_server VCenterESXHostsSensor (fixVirtualizes) Instantiates::Instantiated by cmdb_ci_vmware_instance cmdb_ci_linux/win_server VmwareVmCorrelator Virtualized by::Virtualizes cmdb_ci_esx_server cmdb_ci_vmware_instance vCenter probe chain Runs on::Runs cmdb_ci_esx_server cmdb_ci_vcenter_cluster VCenterClustersSensor 2. Pre-Discovery Checklist ▶ Step 1 — Create VMware Credential (most critical step) Wrong credential type is the #1 cause of vCenter discovery failure. Using SSH, SNMP, or WMI credential types against a vCenter IP will never work. The credential MUST be type "VMware" . Navigate to: Discovery → Credentials → New → Type: VMware

Field Required value Notes Type VMware Not SSH, not SNMP, not WMI Username user@domain.com Format: UPN or DOMAIN\User. Must be a vCenter local or AD account. Password Avoid special XML chars: &, , " in passwords (see Known Issues) IP ranges vCenter IPs only Assign this credential only to the vCenter management IP range, not to all IPs Required vCenter permissions (assign at root vCenter object):

Role: Read-Only (or custom role with read permissions) Global permission: Global → Licenses (required for vCenter license data) "Propagate to children" checkbox: MUST be checked. Without this, the vCenter API cannot traverse the inventory tree. ESX hosts and VMs will not be discovered. Test the credential before running Discovery:

On the credential record → click Test Credential → enter the vCenter IP, leave port as 443, select MID Server → click OK. Expect "Credential validated." Any other result means the credential is wrong.

▶ Step 2 — Verify Firewall Ports (MID Server to vCenter) Port Protocol Purpose Required? 443 HTTPS vCenter SOAP API (primary). All probe chain calls use this port. Required 5480 HTTPS VAMI (vCenter Appliance Management Interface). Required for the port-probe classification method. If using port probe 9443 HTTPS vSphere Web Client API. Required for port-probe method. If using port probe 135, 49152+ TCP WMI/Windows. For Windows Guest OS discovery only — not for vCenter connectivity. For Windows VM OS discovery Test from MID Server: Test-NetConnection -ComputerName -Port 443 (PowerShell) or nc -zv 443 (Linux)

▶ Step 3 — Configure Discovery Schedule (target vCenter IP, not ESX IPs) Navigate to: Discovery → Discovery Schedules → New

IP Range: Enter the vCenter Server's management IP address. Do not enter ESX host IPs. Credential: Select the VMware credential created in Step 1. Include IPs / Networks: Use the specific vCenter management IP; avoid broad /16 ranges that include ESX host IPs — ESX IPs discovered directly return only basic IP/hostname data with no inventory or relationship data. MID Server: Must have network connectivity to vCenter on port 443. Verify via the Test Credential step. Scope tip: One vCenter discovery run discovers ALL ESX hosts and VMs managed by that vCenter. You do not need one schedule entry per ESX host. Adding all ESX IPs individually to the Discovery range wastes resources and produces duplicate or partial CIs. ▶ Step 4 — MID Server Requirements MID Server must have the VMware capability enabled. Navigate to: MID Server record → Capabilities tab → confirm VMware capability is present and active. If multiple MID Servers exist, Discovery MID selection API chooses the best MID based on capability matching. Ensure at least one MID with VMware capability is in the same network segment as vCenter. MID Server JVM must have sufficient heap space for large vCenter inventories. VMware probe payloads can exceed the default 5 MB limit for very large environments (10,000+ VMs). See Section 5 for mid.discovery.max_payload_size . Verify: MID Server log ( agent0.log ) should show no proxy errors or SSL handshake failures when connecting to vCenter. 3. Troubleshoot by Symptom ▶ vCenter runs, only the vCenter CI is created — no ESX hosts, no VMs This is the most common symptom. Work through in order:

Credential type wrong: Open the credential used → confirm Type = VMware. Change if needed, then re-test. "Propagate to children" unchecked: In vCenter, open the permission assigned to the Discovery service account → confirm the Propagate to children checkbox is checked. This is the most commonly missed step. Insufficient permissions: Verify the account has Read-Only role at the root vCenter object AND Global → Licenses privilege. VCenterESXHostsSensor disabled: Navigate to System Definition → Script Includes → search "VCenterESXHostsSensor" → confirm Active = true. VCenterVMsSensor disabled: Same check for "VCenterVMsSensor" and "VmwareVmCorrelator". ECC Queue check: Search ECC Queue for the vCenter IP → confirm probe entries for "VMWarevCenterVMsProbe" are present. If no probe entries: the vCenter Datacenters probe did not fire (credential or port issue). If probe entries exist but errored: see Section 4 Error Reference. ▶ vCenter shows as a "Credentialless" CI in cmdb_ci_computer (not cmdb_ci_vcenter) Symptom: The vCenter appliance (VCSA) appears in cmdb_ci_computer as a generic CI with no relationships to ESXi hosts, clusters, VMs, or datastores. Discovery_source is empty or shows a non-VMware source.

Cause: Discovery hit the vCenter IP but the VMware credential was not selected (credential ordering issue) or authentication failed silently at the VMware API layer.

Verify the VMware credential has a lower Order value than SSH/SNMP credentials in the same IP range. Discovery tries credentials in Order ascending — SSH credentials with lower Order may fire first and classify vCenter as a generic Linux host. Create an IP Service Affinity record: Discovery → Administration → IP Service Affinities → map the vCenter IP to VMware credential type explicitly. Delete the cmdb_ci_computer CI created by the wrong credential, then re-run Discovery. Re-test the VMware credential against the vCenter IP using the Test Credential button. ▶ ESX hosts discovered but "Virtualized by" relationship to Server CIs is missing Root cause: The "Virtualized by::Virtualizes" relationship between ESX server and Linux/Windows Server CIs is created by VCenterESXHostsSensor 's fixVirtualizes function. This function relies on the "Instantiates::Instantiated by" relationship between the VMware Instance CI and the Server CI already existing (created by VmwareVmCorrelator ). If the VMs' OS was not separately discovered, the Server CIs do not exist yet and no relationship can be formed.

Ensure both vCenter Discovery AND IP-based OS Discovery are running for the VMs' IP addresses. vCenter Discovery creates the VMware Instance CI; OS Discovery creates the Server CI. The relationship needs both. If Server CIs exist but no relationship: check the Guest Reconciled flag on the VMware Instance CI and Is Virtual on the Server CI. If both are True but no relationship exists, reset both fields to False and re-run vCenter Discovery. Confirm VmwareVmCorrelator Script Include is Active. ▶ Duplicate ESX server CIs in cmdb_ci_esx_server Cause: ESX identification bypasses IRE and uses three identification indexes in VCenterESXHostsSensor . If the ESX host's correlation_id or hardware UUID changes (ESXi reinstall, vCenter re-registration, vCenter migration), none of the indexes match the existing CI and a new one is created.

Property note: Setting glide.discovery.alter_esx_server_index=true changes identification to use serial_number only (removes correlation_id from the index). Use this when correlation_id is unstable across your infrastructure.

Identify which CI is the "stale" one by comparing last_discovered timestamps. Merge or retire the stale CI. Verify CMDB Deduplication is configured for cmdb_ci_esx_server . If duplicates keep appearing: enable glide.discovery.alter_esx_server_index=true to use stable serial_number identification. ▶ ESX server CI has blank IP address vCenter Discovery retrieves ESX host data from the vCenter API. Some vCenter configurations do not return IP address data in the same payload as other ESX attributes.

Workaround options:

Run a separate SNMP Discovery targeting the ESX host IP directly. This populates the IP address field via a lightweight SNMP walk without re-creating the CI. Manually populate the IP Address field on the ESX server CI and mark it as not overwritable if needed. Verify the VMware API returns IP data: summary.managementServerIp or config.network.vnic[0].spec.ip.ipAddress should be populated in the vCenter inventory for this host. ▶ VM templates or powered-off VMs not appearing in cmdb_ci_vmware_instance By default, vCenter Discovery discovers all VM objects regardless of power state, including templates ( template=true ). If templates are missing, the credential account likely lacks permission on the vSphere template folders specifically.

Powered-off VMs are included in the vCenter API payload. If they are missing: check cmdb_ci_vmware_instance for records with state=poweredOff — they may exist but not be visible in a default list view that filters on state.

For templates specifically: verify the Discovery account has Read-Only permission on the vm folder in the vSphere hierarchy where templates reside, with Propagate to children enabled.

▶ ESX server unexpectedly decommissioned / Operational Status changed to Retired Cause: The built-in business rule "Cascade deprovisioned status to server" on cmdb_ci_vmware_instance runs when a VM is retired or deprovisioned. In some cases it incorrectly cascades the retired status to the parent ESX server CI. This is tracked in DEF0617331 (Can't Confirm state).

Workaround:

Review the Business Rule "Cascade deprovisioned status to server" under System Definition → Business Rules. Confirm the table is cmdb_ci_vmware_instance and the condition correctly filters for VM termination events only. Alternatively, set glide.discovery.mark_esx_servers_as_absent=true to change the behavior from Retired to Absent when ESX hosts are not found in the vCenter payload, which is less destructive than Retired. ▶ Payload size error — discovery stops partway through large vCenter Error in ECC Queue: Payload length 5671972 exceeded limit of 5000000

Occurs in environments with thousands of VMs. The VMware probe returns more data than the default payload size limit allows.

Increase mid.discovery.max_payload_size — set to 10000000 (10 MB) as a starting point. Also increase com.glide.attachment.max_get_size to match or exceed the same value. Restart the MID Server after changing these properties. 4. Error Message Reference Check these error locations: Discovery → Discovery Log → [run] → ECC Queue and MID Server agent0.log .

▶ Authentication failure / Error connecting to host Phase: Scanning / Classification. The MID Server connected to vCenter port 443 but authentication was rejected.

Causes and fixes (in order):

Wrong credential type — must be VMware, not SSH/SNMP. Wrong password. Reset in vCenter and update the ServiceNow credential. Username format incorrect. Try both user@domain.com and DOMAIN\user formats. Special characters in password (&, , ") cause silent XML parsing failure in the SOAP call body. Use Test Credential to confirm. Change the password to exclude these characters. Account locked in Active Directory or vCenter SSO after repeated failed attempts. ▶ Payload length N exceeded limit of 5000000 Phase: Exploration. The VMware probe response for a large vCenter inventory exceeds the MID Server payload size limit.

Increase both mid.discovery.max_payload_size and com.glide.attachment.max_get_size to 10485760 (10 MB) or higher. Restart the MID Server. Discovery has been confirmed stable up to 8.5 MB payload size.

▶ InstanceSoapClient doesn't recover if GetMIDInfo encounters an exception Phase: Exploration. The SOAP client used by the VMware probe enters an unrecoverable error state when the MID Server info call raises an exception. Subsequent probe calls on the same MID Server session fail silently. Tracked in DEF0311630 (Fixed).

Fix: Apply the fix version referenced in DEF0311630. As an interim workaround: restart the MID Server, which clears the stuck SOAP client state. If persistent, check agent0.log for SSL handshake failures that may be triggering the exception.

▶ VMware vCenter VM Tags probe fails SSL certificate validation Phase: Exploration (VM Tags step). When Discovery is run against a vCenter host identified by IP (not FQDN), the VM Tags probe enforces Subject Alternative Name (SAN) validation using the IP address. If the vCenter certificate's SAN does not include the IP (only the FQDN), validation fails. Tracked in DEF0752263 (Work in Progress).

Impact: VM Tags are not populated on VMware Instance CIs. All other ESX/VM discovery continues normally.

Workaround: Use the vCenter FQDN instead of the IP address in the Discovery schedule IP range. Ensure the vCenter certificate's SAN includes the FQDN. Alternatively, configure the vCenter certificate to include both IP SAN and FQDN SAN entries.

▶ Discovery Jobs on Mutual Auth MID Servers seeing a big increase in duration Phase: All phases. MID Servers configured with Mutual Authentication (client certificates) experience significantly longer discovery run times for VMware probes. Tracked in DEF0639562 (Fixed).

Fix: Apply the fix version referenced in DEF0639562. The issue is in the SOAP client certificate negotiation overhead on each probe call. After patching, run times should return to pre-mutual-auth levels.

5. System Properties Reference Navigate to: Discovery → Administration → Properties . Changes take effect on the next Discovery run (no MID Server restart needed unless noted).

Property Default Effect & When to Change glide.discovery.alter_esx_server_index false When true : removes correlation_id from the ESX identification index; uses serial_number only, and adds an FQDN identifier on cmdb_ci_server . Set true when you see duplicate ESX CIs caused by correlation_id changes (ESXi reinstalls, vCenter migrations). glide.discovery.mark_esx_servers_as_absent false When false (default): ESX hosts not found in the vCenter payload are set to Retired . When true : they are set to Absent instead. Set true if you prefer Absent over Retired for temporarily disconnected ESX hosts — Absent is less destructive and easier to re-activate. glide.discovery.esx_server_fields (empty) Comma-separated list of ESX server CI field names that Discovery will skip overwriting . Use when another discovery source (SCCM, SAM, manual entry) populates certain fields and you want Discovery to leave them alone. Example: serial_number,model_number mid.discovery.max_payload_size 5000000 Maximum size in bytes of a probe response payload the MID Server will process. VMware environments with thousands of VMs frequently exceed 5 MB. Increase to 10485760 (10 MB) for large vCenter environments. Requires MID Server restart. com.glide.attachment.max_get_size 5242880 Maximum attachment size (in bytes) the ServiceNow instance will accept from the MID Server. Must be set equal to or higher than mid.discovery.max_payload_size . Set to 10485760 together with the property above when dealing with payload size errors. 6. Probe/Sensor Chain Deep Dive & Step-by-Step Debugging Architecture note: Probes vs Patterns Unlike Switch/Router Discovery which uses the newer Pattern engine ( sa_pattern ), VMware Discovery uses the legacy Probe/Sensor architecture . Probes run on the MID Server; Sensors run on the ServiceNow instance. Probe output is queued in the ECC Queue; the instance processes it via sensor Script Includes. To debug: check Discovery → Discovery Log → [run] → ECC Queue for probe output and error messages. Group A: Scanning & Classification (Phases 1–2) ▶ Step A1 Shazzam probe + port probe scan vCenter IP What it does: Shazzam confirms the host is up (ICMP). The port probe then connects to TCP ports 443, 5480, and 9443. Successful connections on port 5480 ( vmapp_https ) or 9443 ( vmapp6_https ) trigger the vCenter classification path.

Requirements: MID Server must reach the vCenter IP on TCP 443. Ports 5480/9443 are required for the port-probe classification method; port 443 alone is sufficient if using process classifier.

Failure signs: No ECC Queue entries for this vCenter IP at all. Test connectivity: Test-NetConnection -ComputerName -Port 443 from the MID Server host.

▶ Step A2 vCenter Classification → cmdb_ci_vcenter CI type assigned What it does: The SNMP Classification is not used for VMware. Instead, a port classifier rule matches the vmapp_https or vmapp6_https port response to the CI type cmdb_ci_vcenter . This triggers IRE (Phase 3) to create the vCenter CI and then launches the exploration probe chain.

Failure signs: vCenter classified as cmdb_ci_linux_server or cmdb_ci_computer instead of cmdb_ci_vcenter . Cause: SSH credential has a lower Order value and fires first, classifying the VCSA as a Linux server before the VMware credential fires.

Fix: Use IP Service Affinity to explicitly map the vCenter IP to VMware credential type. Delete the incorrectly classified CI and re-run Discovery.

Group B: vCenter Inventory Retrieval (Phase 4 Entry) ▶ Step B1 VMware — vCenter Datacenters probe What it does: The entry-point probe for vCenter exploration. Authenticates to the vCenter SOAP API on port 443 using the VMware credential. Calls RetrievePropertiesEx on the vCenter's ManagedObjectReference (type: Datacenter) to retrieve the full list of datacenters. Each datacenter becomes a child probe invocation for hosts and VMs.

VMware API call: ServiceInstance → PropertyCollector.RetrievePropertiesEx on Datacenter objects

CI created: cmdb_ci_vmware_datacenter for each vSphere datacenter

Failure signs: No ESX or VM CIs created; ECC Queue has no VMWarevCenterVMsProbe entries. Check authentication — the probe fires but SOAP auth failed silently. Review ECC Queue error field for the Datacenters probe entry.

▶ Step B2 VMWare — vCenter Clusters probe + VCenterClustersSensor What it does: Retrieves all ClusterComputeResource objects from each datacenter. For each cluster: name, DRS/HA configuration, resource pool structure, and the list of host MoRefs assigned to the cluster. VCenterClustersSensor creates cmdb_ci_vcenter_cluster CIs and establishes "Runs on::Runs" relationships to ESX server CIs (after ESX CIs are created).

VMware API objects: ClusterComputeResource

Non-blocking: Clusters are optional in some vSphere configurations. Standalone ESX hosts not in a cluster will not appear in this step but are still discovered in Step C1.

Group C: ESX Host Discovery & Identification ▶ Step C1 VMWare — vCenter Hosts probe What it does: For each datacenter/cluster, calls RetrievePropertiesEx on HostSystem managed objects. Retrieves the full set of ESX host attributes: hardware info, configuration, runtime state, and network config. This is the data that feeds into ESX CI creation.

VMware API properties retrieved per HostSystem:

hardware.systemInfo.uuid (maps to vcenter_uuid / correlation_id) hardware.systemInfo.serialNumber (maps to serial_number) hardware.systemInfo.model (maps to model_number) hardware.systemInfo.vendor (maps to manufacturer) hardware.cpuInfo.numCpuCores (maps to cpu_core_count) hardware.cpuInfo.numCpuThreads (maps to logical_processor) hardware.memorySize (maps to ram) summary.config.name (maps to host_name) summary.runtime.connectionState (maps to connection_state) summary.runtime.powerState (maps to power_state) _moref.value (maps to morid) Failure signs: No ESX host data in ECC Queue output. Verify the VMware credential account has Read-Only on the Hosts & Clusters container with Propagate to Children.

▶ Step C2 VCenterESXHostsSensor — create/update cmdb_ci_esx_server CIs Critical: ESX identification does NOT go through IRE. This sensor implements its own 3-key identification: (1) hardware UUID / correlation_id, (2) serial_number, (3) FQDN. If all three fail to match an existing CI, a new CI is created — the source of duplicate ESX records. What it does: Processes the probe output from Step C1. For each ESX host: runs the 3-index identification, creates or updates the cmdb_ci_esx_server CI, populates all fields from the VMware API payload, then calls fixVirtualizes to create the "Virtualized by::Virtualizes" relationship to Server CIs (if they already exist from OS discovery).

CI fields set: name, serial_number, model_number, manufacturer, cpu_core_count, logical_processor, ram, host_name, connection_state, power_state, morid, vcenter_ref, vcenter_uuid, cluster_id, hyper_threading, object_id, last_discovered, discovery_source

Failure signs: ESX CI missing expected fields. Confirm Script Include VCenterESXHostsSensor is Active in System Definition → Script Includes.

Group D: VM Instance Discovery & Relationship Creation ▶ Step D1 VMWarevCenterVMsProbe — retrieve all VM objects What it does: Retrieves all VirtualMachine managed objects from the vCenter inventory. This probe typically appears multiple times in the ECC Queue (one entry per datacenter or batch). Each probe result contains the full property set for every VM in that datacenter scope.

VMware API properties retrieved per VirtualMachine:

config.instanceUuid (maps to vm_instance_uuid — primary identifier) config.uuid (maps to bios_uuid) config.guestFullName (maps to guest_os_fullname) config.guestId (maps to guest_id) config.template (maps to template boolean) config.name (maps to name) config.files.vmPathName (maps to image_path) summary.runtime.powerState (maps to state) summary.config.memorySizeMB (maps to memory) summary.config.numCpu (maps to cpus) runtime.host (MoRef of ESX host — used for parent relationship) Failure signs: Multiple ECC Queue entries with error state. Check the error field — most common: payload too large (increase max_payload_size) or SOAP authentication expired mid-run.

▶ Step D2 VCenterVMsSensor → VmwareVmCorrelator — create VM Instance CIs What it does: VCenterVMsSensor processes each VirtualMachine payload. For each VM: calls VmwareVmCorrelator.processVmInstanceOrTemplate which creates or updates the cmdb_ci_vmware_instance CI (or cmdb_ci_vmware_template if template=true ).

CI fields set on cmdb_ci_vmware_instance: name, vm_instance_uuid, bios_uuid, vcenter_uuid, vcenter_ref, state, guest_id, guest_os_fullname, template, memory, cpus, image_path, host_id, cluster_id, last_discovered

Failure signs: cmdb_ci_vmware_instance records not created. Confirm VmwareVmCorrelator Script Include is Active.

▶ Step D3 VmwareVmCorrelator — create "Instantiates" relationship + set Guest Reconciled Prerequisite for Step C2 fixVirtualizes. If this step doesn't complete successfully, no "Virtualized by" relationship can be created between ESX and Server CIs. What it does: After creating the VMware Instance CI, VmwareVmCorrelator searches for an existing Server CI ( cmdb_ci_server ) whose IP address matches the VM's guest IP (from VMware Tools). If found: creates the "Instantiates::Instantiated by" relationship between the VMware Instance and the Server CI, and sets Guest Reconciled = true on the VMware Instance and Is Virtual = true on the Server CI.

Requirement: VMware Tools must be installed and running on the VM guest for the VM's IP to be available in the VMware API. Without VMware Tools, IP is null and no Server CI match is attempted.

Failure signs: Guest Reconciled = false on VMware Instance CIs. No "Virtualized by" relationships. Fix: ensure VMware Tools is installed on VMs and OS-level Discovery has run on the VM IPs.

Group E: Infrastructure CIs (Networks, Datastores, Folders) ▶ Step E1 VCenterNetworkSensor — vSphere networks and port groups What it does: Retrieves all Network managed objects (standard vSwitches and distributed port groups). Creates cmdb_ci_vcenter_network CIs. These represent the logical network constructs that VMs connect to. Links each network CI to the parent datacenter and to each VM that uses it.

Non-blocking: If this sensor has errors, ESX and VM CIs are still created. Network relationship data may be incomplete but core discovery continues.

▶ Step E2 VCenterDatastoresSensor — vSphere datastores What it does: Retrieves all Datastore managed objects. Creates cmdb_ci_vcenter_datastore CIs representing storage volumes (VMFS, NFS). Populates capacity, free space, and type. Links datastores to the ESX hosts that mount them.

Non-blocking: Datastore data may be missing for restricted accounts that lack permission on the storage layer.

▶ Step E3 VCenterFoldersSensor — vSphere folder hierarchy What it does: Retrieves the vSphere folder tree structure. Creates cmdb_ci_vcenter_folder CIs. Primarily used for Service Mapping topology and for organizing VM CIs in a visual representation of the vSphere inventory. Has no impact on ESX host or VM CI creation.

Non-blocking: Missing folder CIs do not affect ESX or VM discovery completeness.

Expected: "Dual CI" architecture for VMs (not a duplicate)

When both vCenter Discovery AND IP-based OS Discovery run for the same VM, two CIs are created intentionally:

cmdb_ci_vmware_instance Created by vCenter Discovery. Contains vCenter metadata: CPU count, memory, image_path, guest_os_fullname, template flag, vcenter_ref, vcenter_uuid. cmdb_ci_linux/win_server Created by OS Discovery. Contains OS-level data: processes, services, users, software installs, disk layout. These two CIs are linked via the "Instantiates::Instantiated by" relationship. This is the intended CMDB model, not a duplicate. Do not merge or delete either CI without understanding which data each carries.

7. Known Issues & Limitations ▶ KB0830586 — Duplicate ESX server records when correlation_id changes Root cause ESX identification uses VCenterESXHostsSensor (not IRE). When the correlation_id changes (ESXi reinstall, vCenter re-registration, vCenter migration), none of the 3 identification indexes match the existing CI and a new CI is created. Symptom Multiple cmdb_ci_esx_server records for the same physical host with different correlation_id values. Workaround Set glide.discovery.alter_esx_server_index=true to switch to serial_number-based identification. Delete the stale duplicate CI. Also see KB1123141 for identification behavior details. ▶ KB0750033 — IP address not populated on ESX server CIs after vCenter Discovery Symptom vCenter Discovery runs successfully and creates all ESX CIs, but the ip_address field is blank on cmdb_ci_esx_server records. Impact No IP address on ESX CIs prevents OS-level Discovery from correlating a scan of the ESX management IP back to the correct cmdb_ci_esx_server record. Workaround Run a lightweight SNMP scan targeting ESX host IPs to populate ip_address without replacing other fields. Or populate manually and set the field to not be overwritten via glide.discovery.esx_server_fields . ▶ DEF0752263 — VM Tags probe fails SSL certificate SAN validation State Work in Progress (active defect) Symptom VM Tags not discovered. SSL certificate validation error in ECC Queue for the VM Tags probe when Discovery targets vCenter by IP (not FQDN). Root cause The VM Tags probe enforces SAN validation using the IP address. If the vCenter certificate's SAN does not list the IP (only the FQDN), the TLS handshake is rejected. Workaround Use vCenter FQDN in the Discovery schedule IP range instead of the IP. Alternatively, reissue the vCenter certificate to include an IP SAN entry. ▶ DEF0601391 / DEF0601714 — Missing relations from ESXi discovery State: Working as Expected (behavior confirmed, no code change planned)

DEF0601391: ESXi server CIs are created but missing certain parent/child relationships. DEF0601714: Some relations between vCenter CI and ESX server CI not populated.

Root cause: These relationships depend on the timing of the probe chain. If the datacenter/cluster CIs have not been fully committed when the ESX sensor runs, the foreign key references resolve to null and the relationships are not created on that run. They are typically present after the second Discovery run.

Workaround: Run vCenter Discovery twice in sequence. The second run has all parent CIs already committed and creates all missing relationships. Configure a recurring Discovery schedule to ensure the relationship data stays current.

▶ DEF0821588 — ESX OS Software Install records: display_name hardcoded, stale versions not deactivated State: Fixed

Software Installed records on ESX server CIs have a hardcoded display_name , the last_scanned field is not updated on Discovery runs, and stale version records are not marked inactive after an ESX upgrade.

Fix: Apply the fix version referenced in DEF0821588. Until patched, stale software install records may persist after ESX host upgrades — manually deactivate outdated records if SAM or ITAM workflows depend on accurate ESX software inventory.

▶ VM Tag discovery requires vCenter 6.0+ and specific permissions VM Tags are populated via the vSphere REST API (not the SOAP API). This API was introduced in vSphere 6.0. VMs managed by vCenter 5.x will have no tag data populated.

Permission required: The Discovery account needs READ permission at the vCenter level (not just at resource level) for the tagging namespace. The Read-Only role at root with Propagate to Children covers this in most vCenter configurations, but custom roles that exclude the com.vmware.content.library.vm.tag.read privilege will silently omit tags.

Also see DEF0752263 above for the SSL certificate issue that can prevent tag discovery regardless of permissions.

ServiceNow Discovery — VMware ESX / vCenter Pattern | Zurich / Xanadu | cmdb_ci_esx_server | June 2026 For questions or corrections, use the feedback button on this article. Related guides: Network Switch Discovery — Network Router Discovery .