How KVA Collects Name and Hostname — In-Depth Flow of Events - Support and Troubleshooting

How KVA Collects Name and Hostname — In-Depth Flow of Events Issue .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: ; } } Depending on Discovery Source, the method and format of Discovering the CI Name/Hostname may differ.

This KB explores in the case of Kubernetes Visibility Agent (KVA).

Release .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: ; } } ALL

Resolution .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: ; } } Step 1 — KVA connects to the Kubernetes API KVA establishes a long-lived watch connection to the Kubernetes API server, equivalent to:

kubectl get nodes -o json --watch

It first fetches all existing nodes, then continuously receives updates as the cluster state changes. All node data — including name and hostname — comes from this single stream. No separate DNS lookup or OS-level probe is performed at any point.

Step 2 — KVA reads the Node object From each node object, KVA reads: * The node name as registered in Kubernetes at cluster join time * The node's internal IP address No hostname address entry is separately read. Whatever name Kubernetes has stored for the node is exactly what KVA works with.

Step 3 — KVA maps to cmdb_ci_linux_server fields KVA applies the following logic when populating the CI: * If the node name contains a dot (i.e. it is an FQDN): * name → everything before the first dot (short hostname) * host_name → full node name as-is (FQDN) * If the node name does not contain a dot (i.e. it is already a short hostname): * name → node name as-is * host_name → same value as name

This means: Node registered in Kubernetes as name (CMDB) host_name (CMDB)

So the format of both fields is entirely determined by how the node was registered in the Kubernetes/OpenShift cluster at join time — not by KVA itself. NOTE: KVA will always set name to the short (non-qualified) hostname. If the name field on a CI contains an FQDN, that value was not set by KVA — it was set by another discovery source that previously discovered the same server.

Step 4 — Pre-Sensor script runs (Update Set attached) Before the payload reaches IRE, the pre-sensor script checks whether the CI already exists in the CMDB and if so, preserves the existing name value. This prevents KVA from overwriting a name that was already set by another discovery source. Note: This script only activates when the CI payload contains an object_id. "For this specific CI 'X', object_id is not populated, so the script does not apply."

Step 5 — Payload submitted to IRE The final name and host_name values are submitted to IRE for CI identification and reconciliation.

Observed behavior on sample CI 'X': This CI is discovered only by KVA via OpenShift. The node was registered in OpenShift with its FQDN (x.sample.domain.com), so KVA correctly sets: * name = x (short hostname) * host_name = x.sample.domain.com (FQDN) This is correct and expected OOB behavior.