16.1 Configure Service Discovery
Key Takeaways
Service Discovery identifies supported services and relationships; it does not prove application transaction health.
Credential-less discovery still requires compatible Tools/plugins and authorized integration access.
Verify a known service/port and current timestamp on representative VMs.
Use release-specific troubleshooting only after matching the documented failure condition.
Discovery Is a Specific Monitoring Task
Service Discovery identifies supported services and communication relationships inside guest VMs. It helps an operator understand what runs where and how tiers relate. This differs from collecting hypervisor CPU/memory metrics and from obtaining detailed application response-time or transaction measurements. Discovering a database process does not establish that the database serves requests correctly.
Operations can use VMware Tools-based discovery paths, including supported credential-less discovery. Credential-less means that a supported guest communication/plugin mechanism avoids separately supplied guest credentials for that discovery mode. It does not mean zero software, zero privileges or zero resource use. Tools/plugin compatibility and the required vCenter privileges still matter.
Validate the Prerequisites
Identify the supported Windows/Linux guest types, VMware Tools or open-vm-tools version, Service Discovery plugin and Operations/vCenter versions. Confirm that the VM is powered on, its Tools service is healthy and the Operations integration can discover the VM. For Linux, the supported open-vm-tools discovery plugin/package must be present where required; a healthy basic Tools heartbeat alone is insufficient.
| Layer | Verification | Why it matters |
|---|---|---|
| Inventory | The VM is present in the intended vCenter account | Discovery needs the correct managed object |
| Guest | Supported OS and healthy Tools/plugin | The communication path must expose discovery data |
| Authorization | Required integration/guest-operation permissions | Read-only inventory access may not authorize every discovery task |
| Discovery configuration | Supported adapter/options and target scope | Disabled or incorrectly scoped discovery produces no services |
| Result | Current service objects and relationships | Old objects can remain after collection stops |
Keep a representative set of test VMs: one supported guest with a known web service, one with a database and one that should not expose that service. This allows you to check both missing detections and false assumptions. Do not select hundreds of production VMs before confirming the basic configuration with a small sample.
Configure and Observe
Configure the supported Service Discovery integration/options and collection scope for the installed Operations release. Select the correct vCenter connection and collector where applicable. Use credential-less discovery only where its prerequisites are satisfied; use a supported credentialed mode when needed rather than assuming every guest can use the same mechanism.
Allow discovery to complete, then inspect the selected VM's discovered services and relationship views. Compare the service name and port with the actual guest configuration. A process can listen on a nondefault port, multiple processes can share a service family and a service can be configured but not currently running. A failed signature match is not proof that no application exists.
Interpret Relationships
A relationship map is evidence of observed/discovered communication, not a complete architecture contract. Sampling windows, encrypted protocols, firewalls and inactive connections can affect visibility. Use the map to guide maintenance and troubleshooting, then confirm critical dependencies with application owners and additional telemetry.
For example, a front-end VM may depend on a database VM that also serves a nightly batch application. A discovery run outside the batch window may show only the front-end relationship. Before shutting down the database VM, check the full operating cycle and documented application dependencies. A missing line in one map does not authorize a maintenance outage.
Diagnose Failed Collection
When discovery fails for one VM, inspect its guest/plugin health and relevant discovery task/error before changing every adapter. When all VMs in an account fail, inspect common permissions, account configuration, vCenter connectivity and collection state. Preserve the exact error; an authentication failure, unsupported guest and plugin synchronization problem are different conditions.
Broadcom KB 427145 documents credential-less discovery issues involving particular VMware Tools builds and recommends the Linux open-vm-tools discovery plugin path where applicable. Treat this as a version-specific diagnosis. Do not indiscriminately edit the vCenter Managed Object Browser or delete discovery namespaces on healthy VMs because a troubleshooting article describes that remedy for a specific condition.
Keep Discovery Current
Services move, ports change and VMs are replaced. Review timestamps and stale service objects after deployments and upgrades. Verify the intended scope when adding a vCenter or changing group/tag rules. Restrict discovery outputs according to the team's access needs because service names and dependency maps can reveal sensitive application topology.
A useful lab completion record names the supported guest and Tools/plugin versions, integration scope, discovered service/port, relationship evidence and the collection timestamp. Test service stop/start in a disposable guest and observe how the result changes. This proves discovery behavior rather than merely proving that a configuration screen was saved.
For the exam, distinguish a request to identify services/dependencies from a request to monitor application-specific performance. The former calls for discovery; the latter often requires application monitoring and its own agent/plugin configuration. Both can be used together, but neither should be described as automatically delivering the other's full function.
Review Takeaways
- Service Discovery identifies supported services and relationships; it does not prove application transaction health.
- Credential-less discovery still requires compatible Tools/plugins and authorized integration access.
- Verify a known service/port and current timestamp on representative VMs.
- Use release-specific troubleshooting only after matching the documented failure condition.
A service map identifies a database process. What does that prove?
That all database queries meet their latency objective
That the service was discovered under the supported collection path, not that transactions are healthy
That no application monitoring is needed
That every backup is restorable
Sections you finish are checked off in the contents.