Investigate Proxmox-imported k8s worker device identity and missing IPs #3540

New issue

Open

opened 2026-06-05 23:24:12 +00:00 by mfreeman451 · 0 comments

mfreeman451 commented

2026-06-05 23:24:12 +00:00

Owner

Problem

Kubernetes worker VMs discovered by the Proxmox inventory integration are not merging cleanly with newly installed ServiceRadar agents. Several Proxmox-imported VM rows also appear to lack IP addresses even though the workers are active hosts. This makes the devices list confusing and prevents the expected agent lightning-bolt state from landing on the existing Proxmox VM devices.

Live demo evidence from 2026-06-05

platform.ocsf_agents shows all seven agents connected on version 1.2.94.
Five k8s worker agents were linked to the same device UID: sr:16c172dc-4b30-4117-a8bb-e0a9630e9cca.
That collapsed device had mixed identity: hostname from one worker, IP from another, and metadata/aliases from multiple workers.
platform.device_identifiers had these agent_id identifiers all pointing at the same UID: agent-k8s-cp2-worker1, agent-k8s-cp2-worker2, agent-k8s-cp2-worker3, agent-k8s-cp3-worker1, agent-k8s-cp3-worker2.
Proxmox VM records exist separately and carry strong MAC-backed identifiers, for example proxmox:vm:BC:24:11:... plus mac identifiers, but the agent-created rows do not currently carry those MAC identifiers.
The older Proxmox imported rows for %k8s-cp% need a hard review: some have MAC/integration identity but no usable IP, and some appear duplicated by older hostname-based integration IDs.

Questions to answer

Is the Proxmox plugin failing to collect guest-agent IP/interface runtime data, or is the ingestor dropping it?
Why do Proxmox-imported %k8s-cp% VMs have MAC identity but missing IP addresses?
Are old hostname-based integration_id rows (proxmox:vm:k8s-*) supposed to be merged into the newer MAC-backed proxmox:vm:<MAC> rows?
Should agent enrollment report host MAC/system identity so DIRE can merge installed agents into Proxmox-discovered VM records by strong identifiers?
What repair job/migration is needed for already-poisoned device_identifiers, device_alias_states, and merged ocsf_devices rows in demo?

Expected outcome

Proxmox-discovered VM rows include stable MAC identity and best-effort IP/interface data.
Installing an agent on a previously discovered VM updates/merges the existing VM device record instead of creating duplicates or collapsing multiple agents into one device.
DIRE does not let stale weak alias/IP state or stale agent_id identifiers override stronger VM/agent identity.

This was found while working netflow-to-process attribution and agent-side netprobe rollout. Keep this issue separate from netprobe CPU/UI work so the attribution branch does not absorb a broader inventory repair project.

## Problem Kubernetes worker VMs discovered by the Proxmox inventory integration are not merging cleanly with newly installed ServiceRadar agents. Several Proxmox-imported VM rows also appear to lack IP addresses even though the workers are active hosts. This makes the devices list confusing and prevents the expected agent lightning-bolt state from landing on the existing Proxmox VM devices. ## Live demo evidence from 2026-06-05 - `platform.ocsf_agents` shows all seven agents connected on version `1.2.94`. - Five k8s worker agents were linked to the same device UID: `sr:16c172dc-4b30-4117-a8bb-e0a9630e9cca`. - That collapsed device had mixed identity: hostname from one worker, IP from another, and metadata/aliases from multiple workers. - `platform.device_identifiers` had these `agent_id` identifiers all pointing at the same UID: `agent-k8s-cp2-worker1`, `agent-k8s-cp2-worker2`, `agent-k8s-cp2-worker3`, `agent-k8s-cp3-worker1`, `agent-k8s-cp3-worker2`. - Proxmox VM records exist separately and carry strong MAC-backed identifiers, for example `proxmox:vm:BC:24:11:...` plus `mac` identifiers, but the agent-created rows do not currently carry those MAC identifiers. - The older Proxmox imported rows for `%k8s-cp%` need a hard review: some have MAC/integration identity but no usable IP, and some appear duplicated by older hostname-based integration IDs. ## Questions to answer - Is the Proxmox plugin failing to collect guest-agent IP/interface runtime data, or is the ingestor dropping it? - Why do Proxmox-imported `%k8s-cp%` VMs have MAC identity but missing IP addresses? - Are old hostname-based `integration_id` rows (`proxmox:vm:k8s-*`) supposed to be merged into the newer MAC-backed `proxmox:vm:<MAC>` rows? - Should agent enrollment report host MAC/system identity so DIRE can merge installed agents into Proxmox-discovered VM records by strong identifiers? - What repair job/migration is needed for already-poisoned `device_identifiers`, `device_alias_states`, and merged `ocsf_devices` rows in demo? ## Expected outcome - Proxmox-discovered VM rows include stable MAC identity and best-effort IP/interface data. - Installing an agent on a previously discovered VM updates/merges the existing VM device record instead of creating duplicates or collapsing multiple agents into one device. - DIRE does not let stale weak alias/IP state or stale `agent_id` identifiers override stronger VM/agent identity. ## Related context This was found while working netflow-to-process attribution and agent-side netprobe rollout. Keep this issue separate from netprobe CPU/UI work so the attribution branch does not absorb a broader inventory repair project.