--- sourceDocument: Australia IT Operations Management sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-operations-management Release : - australia ft:locale : - en-US ft:publication_title : - Australia IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # VMware NSX load balancer # VMware NSX Advanced load balancer discovery {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of VMware NSX Advanced load balancer discovery The ServiceNow Discovery application includes a VMware NSX Advanced load balancer discovery pattern designed to identify VMware NSX load balancers by leveraging REST APIs. This pattern is triggered by the NSX HTTP classifier in response to an HTTP-Classify probe. There are two distinct patterns: one for VMware NSX S series (legacy) and one for NSX-T series, both delivering the same functionality and data collection. Show full answer Show less To enable this discovery, customers must ensure their Discovery and Service Mapping Patterns applications are updated to the latest versions from the ServiceNow Store. ## Prerequisites * **Enable NSX Basic Authentication:** Configure this within VMware NSX to allow authenticated API access. * **Update Key ServiceNow Applications:** Verify that CMDB CI Class Models, Visibility Content, and Discovery and Service Mapping Patterns are current. * **Configure Basic Authentication Credentials:** Set credentials on the ServiceNow AI Platform with API permissions appropriate for NSX or NSX-T endpoints. * **Verify HTTP Discovery Trigger:** HTTP discovery runs only if SSH or SNMP discovery fails, targeting the NSX Main Controller IP. * **Create a Discovery Schedule:** Schedule or run quick discoveries on the NSX Main Controller IP to initiate load balancer discovery. ## Data Collected and CMDB Impact The discovery populates Configuration Items (CIs) in the CMDB with detailed load balancer information, including: * **NSX Load Balancer:** Edge name, Edge ID, IP address, and operational status. * **Load Balancer Service:** Virtual server name, IP address, object ID, port, and listener protocol. * **Load Balancer Pool:** Pool name and object ID. * **Load Balancer Pool Member:** Member name, IP address, object ID, and service port. * **Cloud Load Balancer Health Service:** Monitor name, object ID, timeout, check interval, monitor type, request path, and max retries. The discovery also creates CI relationships supporting the load balancer architecture, such as which services run on which load balancers, pool ownership, hosting details, and monitoring dependencies. These relationships are visualized in Dependency Views to provide clear mapping of the load balancer environment. ## Troubleshooting * **REST Timeout Errors During Discovery:** If the MID Server cannot process REST responses within the default 30-second timeout (`mid.sa.cloud.requesttimeout`), increase this parameter on the MID Server and rerun discovery. * **Pattern Designer Timeout Errors:** For pattern debugging timeouts (default 240 seconds, `sa.debugger.maxtimeout`), increase the parameter on the MID Server to avoid failures during debug sessions. Adjusting these parameters ensures efficient processing of large deployments and smoother discovery and debugging operations. The ServiceNow Discovery application uses the VMware NSX Advanced load balancer discovery pattern to find VMware NSX load balancers. Discovering some of these resources might require updating to the latest version of the Discovery and Service Mapping Patterns application from the ServiceNow Store. The pattern uses a set of REST APIs to find the load balancers. It is triggered by the NSX HTTP classifier that responds to the HTTP - Classify probe. For more information, see [HTTP device discovery](https://www.servicenow.com/docs/tuBt0~qLhwxwwKTnTVEMmw "Discovery can find devices that use the HTTP protocol."). Note: There are two patterns available. The legacy VMware NSX Load Balancer pattern is for the S series. The new VMware NSX-T Load Balancer pattern is for the T series. The functionality and collected information remain the same. ## Request apps on the Store {#vmware-nsx-lb-discovery__section_gvb_cql_rlb} Visit the [ServiceNow Store](https://store.servicenow.com/sn_appstore_store.do#!/store/home) to view all the available apps, and for information about submitting requests to the store. For cumulative release notes information for all released apps, see the [ServiceNow Store version history release notes](https://www.servicenow.com/docs/r/store-release-notes/sn-store-release-notes.html).{#vmware-nsx-lb-discovery__inline-send-to-store} ## Prerequisites {#vmware-nsx-lb-discovery__section_fn4_km5_wkb} Enable NSX Basic Authentication : In VMware NSX, enable NSX Basic Authentication. Verify that the applications are up to date : * CMDB CI Class Models * Visibility Content * Discovery and Service Mapping Patterns {#vmware-nsx-lb-discovery__ul_gkf_5wj_ncc} Configure basic authentication credentials : On the ServiceNow AI Platform, configure basic authentication credentials. The credentials must have the following API permissions: * NSX: * /api/4.0/edges * /api/4.0/edges/\loadbalancer/config {#vmware-nsx-lb-discovery__ul_mcw_2zs_ncc} * NSX-T: /api/v1/edge-clusters {#vmware-nsx-lb-discovery__ul_lcw_2zs_ncc}For more information about basic authentication credentials, see [Basic authentication credentials](https://www.servicenow.com/docs/access?context=r_BasicAuthCredentialsForm&version=australia&pubname=australia-platform-security&ft:locale=en-US). Verify HTTP discovery is triggered against the NSX Main Controller IP : The HTTP discovery is triggered only if SSH or SNMP discovery is unsuccessful. Create a discovery schedule : Create the discovery schedule for VMware NSX load balancer discovery or run a quick discovery on the IP address of the NSX Main Controller. For more information about running a quick discovery, see [Run a Quick Discovery](https://www.servicenow.com/docs/VO0owNull6HAfXGFWMKxhg#t_DiscoverNow "Quick Discovery, or DiscoverNow, allows an administrator to run a CI Configuration discovery on a single IP address without requiring a schedule."). ## Data collected by Discovery for VMware NSX Advanced load balancer {#vmware-nsx-lb-discovery__section_rvw_lm5_wkb} Discovery populates the data in the CMDB when running the VMware NSX Advanced load balancer patterns. {#vmware-nsx-lb-discovery__table_mvv_5gk_ncc__entry__2} | Field | Description | |-|-| | Name \[name\] | Edge name. | | Object ID \[object_id\] | Edge ID. | | IP Address \[ip_address\] | IP address of the NSX Main Controller. | | Operational status \[operational_status\] | Load balancer status: Active or inactive. | [Table 1. NSX Load Balancer \[cmdb_ci_nsx_lb\]] {#vmware-nsx-lb-discovery__table_mvv_5gk_ncc} {#vmware-nsx-lb-discovery__table_ugr_vgk_ncc__entry__2} | Field | Description | |-|-| | Name \[name\] | Virtual server name. | | IP Address \[ip_address\] | Virtual server IP address. | | Object ID \[object_id\] | Virtual server object ID. | | Port \[port\] | Virtual server port with which to communicate. | | Listener Protocol \[listener_protocol\] | Listener protocol. For example: HTTP, HTTPS. | [Table 2. Load Balancer Service \[cmdb_ci_lb_service\]] {#vmware-nsx-lb-discovery__table_ugr_vgk_ncc} {#vmware-nsx-lb-discovery__table_kjs_vgk_ncc__entry__2} | Field | Description | |-|-| | Name \[name\] | Pool name. | | Object ID \[object_id\] | Pool object ID. | [Table 3. Load Balancer Pool \[cmdb_ci_lb_pool\]] {#vmware-nsx-lb-discovery__table_kjs_vgk_ncc} {#vmware-nsx-lb-discovery__table_tgt_vgk_ncc__entry__2} | Field | Description | |-|-| | Name \[name\] | Pool member name. | | IP Address \[ip_address\] | Pool member IP address. | | Object ID \[object_id\] | Pool member object ID. | | Service port \[service_port\] | Pool member port with which to communicate. | [Table 4. Load Balancer Pool Member \[cmdb_ci_lb_pool_member\]] {#vmware-nsx-lb-discovery__table_tgt_vgk_ncc} {#vmware-nsx-lb-discovery__table_bf5_vgk_ncc__entry__2} | Field | Description | |-|-| | Name \[name\] | Monitor name. | | Object ID \[object_id\] | Monitor object ID. | | Timeout in seconds \[timeout_sec\] | Time in seconds to wait for a response. | | Interval in seconds \[check_interval_sec\] | Interval in seconds after which the monitor sends the request again. | | Monitor type protocol \[monitor_type\] | Monitor type. For example: HTTP, HTTPS, TCP. | | Request path \[request_path\] | Path where the monitor sends the request. | | Max retries \[max_retries\] | The maximum number of times the resource is tested before it is declared "Down". | [Table 5. Cloud Load Balancer Health Service \[cmdb_ci_lb_health_service\]] {#vmware-nsx-lb-discovery__table_bf5_vgk_ncc} The Dependency Views map shows all discovered load balancer CIs and the relationships between them. ## CI relationships {#vmware-nsx-lb-discovery__section_dwt_4m5_wkb} Discovery creates these relationships to support the VMware NSX load balancer discovery.{#vmware-nsx-lb-discovery__table_qr4_zn5_wkb__entry__3} | CI | Relationship | CI | |-|-|-| | Load Balancer Service \[cmdb_ci_lb_service\] | Runs on::Runs | NSX Load Balancer \[cmdb_ci_nsx_lb\] | | Load Balancer Service \[cmdb_ci_lb_service\] | Uses::Used by | Load Balancer Pool \[cmdb_ci_lb_pool\] | | Load Balancer Pool \[cmdb_ci_lb_pool\] | Hosted on::Hosts | NSX Load Balancer \[cmdb_ci_nsx_lb\] | | Load Balancer Pool \[cmdb_ci_lb_pool\] | Owns::Owned by | Load Balancer Pool Member \[cmdb_ci_lb_pool_member\] | | Cloud Load Balancer Health Service \[cmdb_ci_lb_health_service\] | Hosted on::Hosts | NSX Load Balancer \[cmdb_ci_nsx_lb\] | | Cloud Load Balancer Health Service \[cmdb_ci_lb_health_service\] | Used by::Uses | Load Balancer Pool \[cmdb_ci_lb_pool\] | [ ] {#vmware-nsx-lb-discovery__table_qr4_zn5_wkb} ## Troubleshooting {#vmware-nsx-lb-discovery__section_bjf_rm5_wkb} If the mapping process does not proceed as you expected, follow the following suggestions.{#vmware-nsx-lb-discovery__table_ggn_ypj_yhb__entry__3} | Symptom | Cause | Solution | |-|-|-| | Discovery fails. The discovery message contains the information about an error caused by the REST timeout. | There are many CIs sending the REST call response in the deployment. The MID Server cannot process the REST call response without exceeding the time limit controlled by the mid.sa.cloud.request_timeout parameter. | By default, the mid.sa.cloud.request_timeout parameter is set to 30000 milliseconds. Increase the value of this parameter on the relevant MID Server and run discovery again. Note: If the Configuration Parameters related list for the relevant MID Server does not show this parameter, you may need to add it. | | Pattern Designer fails during a debug session. The Pattern Designer message contains information about an error caused by a timeout. | The Pattern Designer fails because of a timeout during pattern debugging (and not during discovery). | By default, the sa.debugger.max_timeoutparameter is set to 240 seconds. Increase the value of this parameter on the relevant MID Server. | [ ] {#vmware-nsx-lb-discovery__table_ggn_ypj_yhb}