Raised from real testing (CEO, 2026-08-06): guests discovered from a Proxmox host arrive with no IP, no services and no software.
Why, honestly
That is the current design, not a defect: the host can only report what the hypervisor knows about a guest — vmid, name, state, cores, memory, MACs, SMBIOS UUID. IPs, services and installed software live inside the guest OS, which the hypervisor cannot see. ADR-0095 §4 deliberately excluded qemu-guest-agent queries from v1, for stated reasons: they hang up to the agent timeout on wedged guests, they require agent: 1 plus the guest package installed, and they add nothing to identity.
So today there are two ways a guest gets full detail, and only one is built:
- Install the agent inside the guest (built, and the intended path): full inventory, and ADR-0095 §6 converges it with the host's view into one node. This is the answer for guests you manage.
- Enrich from the host via qemu-guest-agent (not built):
qm guest cmd <vmid> network-get-interfaces / get-osinfo would give IPs and an OS string for guests that have the QEMU guest agent running — no software inventory, ever.
The decision to take
Whether to add best-effort guest-agent enrichment for the IP/OS fields only, strictly bounded (short timeout, absent when unavailable, never blocking the report, never an identity source), so that guests without their own lazyit agent stop looking empty on the map — or to leave v1's line and make the UI state plainly that a guest's detail arrives when the agent is installed inside it.
Whichever way it goes, the empty-looking guest row is a UX problem right now: the map shows a node with nothing in it and no explanation of why or what to do about it. That part should be addressed regardless.
Refs #1217 · ADR-0095 §4 (the deferral and its reasons) · §6 (convergence)
Raised from real testing (CEO, 2026-08-06): guests discovered from a Proxmox host arrive with no IP, no services and no software.
Why, honestly
That is the current design, not a defect: the host can only report what the hypervisor knows about a guest — vmid, name, state, cores, memory, MACs, SMBIOS UUID. IPs, services and installed software live inside the guest OS, which the hypervisor cannot see. ADR-0095 §4 deliberately excluded qemu-guest-agent queries from v1, for stated reasons: they hang up to the agent timeout on wedged guests, they require
agent: 1plus the guest package installed, and they add nothing to identity.So today there are two ways a guest gets full detail, and only one is built:
qm guest cmd <vmid> network-get-interfaces/get-osinfowould give IPs and an OS string for guests that have the QEMU guest agent running — no software inventory, ever.The decision to take
Whether to add best-effort guest-agent enrichment for the IP/OS fields only, strictly bounded (short timeout, absent when unavailable, never blocking the report, never an identity source), so that guests without their own lazyit agent stop looking empty on the map — or to leave v1's line and make the UI state plainly that a guest's detail arrives when the agent is installed inside it.
Whichever way it goes, the empty-looking guest row is a UX problem right now: the map shows a node with nothing in it and no explanation of why or what to do about it. That part should be addressed regardless.
Refs #1217 · ADR-0095 §4 (the deferral and its reasons) · §6 (convergence)