Peek into VM/CT for docker information without installing an additional agent?

[Scott8586]

Is there a reasonable way to peek into a VM/CT for docker information? Is the recommended way to setup a Machines agent in that VM/CT to evaluate docker entities?

[pulse-triage[bot]]

For a VM, install Pulse Agent inside the guest with Docker monitoring enabled; the Proxmox API or node agent cannot see its Docker inventory. For an LXC, that guest-local route also works, or a Proxmox node agent can collect a limited Docker summary if you explicitly enable Discover Docker in LXC guests in Settings → System → General (off by default). The Pulse server itself does not need the Docker socket.

How Pulse handles triage

[Scott8586]

I've now tried this, and one LXC+docker is visible and showing the running containers, but another LXC+docker setups remains opaque.

Both are on PVE 9.1.6; Pulse 6.4.5
what works: LXC Debian 13, nesting=1,keyctl=1, unprivileged: 1; Docker version 26.1.5+dfsg1, build a72d7cd
what doesn't work: LXC Debian 12, nesting=1; Docker version 29.8.2, build 7fc2dff,

[pulse-triage[bot]]

The host-side path in 6.4.5 requires /var/run/docker.sock and a working Docker CLI in the owning node’s pct exec context; the version and keyctl differences alone do not establish the cause. Are both LXCs on the same PVE node, and what does this one-off check show for the missing guest when run as root on its owning node (replace 123 with its VMID)?

timeout --kill-after=2s 15s pct exec 123 -- sh -c '
  command -v docker || exit
  if test -S /var/run/docker.sock; then
    printf "default_socket=present\n"
  else
    printf "default_socket=absent\n"
  fi
  docker version --format "server={{.Server.Version}}" || exit
  docker ps -a --format "{{.State}}"
'

Share only this output, redact any private address in an error, and stop if it times out — this separates guest entry/socket/daemon failures from Pulse’s collection path.

How Pulse handles triage

[Scott8586]

Not on the same PVE. Results of script:
/bin/docker
default_socket=present
server=29.8.2
running
running
running
running
running
running
running
running
running
running
running
running
running

[pulse-triage[bot]]

That confirms Docker and its container list are reachable through root pct exec on the missing guest’s node, but not yet through Pulse’s agent. Host-side discovery uses a connected command-capable Pulse agent on each guest’s owning PVE node; an agent on the other node or API-only monitoring does not cover it. Is there a connected Pulse agent on that PVE node with command execution (--enable-commands) enabled and permission to run pct exec?

How Pulse handles triage

[Scott8586]

No, that's it - the failing pve node does not have --enable-commands set. I will attempt to adjust the running of that agent.

[Scott8586]

After adding --enable-commads to the systemctl startup, the Infrastructure section for that node says "Remote control blocked". I tried adjusting API permissions, but that hasn't made a difference; how do I unblock remote control?

[pulse-triage[bot]]

That label means the agent reports commands enabled but Pulse has no admitted command channel; changing Proxmox API permissions does not unblock it. In Pulse’s Agent Doctor, what reason code/text does that node show for command authority or credential scope—please share only that reason, not tokens, hostnames, addresses or a diagnostics bundle? A missing agent:exec scope requires a new command-enabled credential from Pulse’s install flow, not just a service flag; do not broaden node command access if guest-local Docker monitoring with commands disabled meets your needs.

How Pulse handles triage

[Scott8586]

This is the only thing related to exec for that node in Agent Doctor:

"agent:XXXXX · Updater: Automatic updates ready · Privilege: root · commands command-capable · credential grants exec"

(same as the working PVE node)

[pulse-triage[bot]]

That confirms command-capable scope, not a connected command session; automatic update readiness is separate. On the affected PVE node, inspect sudo journalctl -u pulse-agent.service --since '15 minutes ago' -n 200 --no-pager --output=cat locally and share only the command-channel dial websocket or registration failed error reason (or say no such entry is present), so we can separate connection/handshake failures from credential binding. Redact tokens, URLs, hostnames, addresses and IDs; do not post the full journal or change permissions.

How Pulse handles triage

[Scott8586]

I must have missed it earlier, it's working now.