Sorry in advance for the wall of (AI assisted) text. This is something I've been sitting on for a while and come back to every few months to see where it's up to so I thought I'd try and get some constructive discussion happening here in the forums

For quite some time now, it seems like the "Docker VM" is probably the most common homelab workload on XCP-ng (not to mention some of those other moxie hypervisors), and right now those users get zero visibility in XO 6. Unfortunately, I've actually seen this result in a few peers steering away from XCP-ng/XOA (their loss...).

We used to have this feature way back in the pre-covid times, but alas, it is now but a relic. A quick search through the forums surfaces some recurring requests (2361, 2404, 4338, 6845, 7356...) and back in 2019 the answer was already "the Citrix plugin is a dead end, we might use something else" — but that something else never quite materialized.
Meanwhile the broken xscontainer package still ships and the wiki still documents it as a working procedure, so people (i.e me...) keep following the docs into a wall of cryptic tracebacks.
It's safe to assume I went down this rabbit hole (again...not for the first time...), but eventually I get steered towards patching dom0 Python and downgrading guest sshd crypto, and decide to bail out.
Nobody should do that in 2026.

Because upstream XenServer dropped the feature completely, this is a genuine differentiation opportunity rather than legacy maintenance: container visibility in the VM view would be something XCP-ng/XO offers that the commercial upstream simply doesn't (and would also get to parity with that other hypervisor previously alluded to...).

With XenServer 8 having removed the Container Management supplemental pack entirely, and the old xscontainer package being effectively broken against any modern guest (the paramiko/ssh-rsa issue from topic 6845, plus a couple more bugs...), I wanted to float a proposal for bringing this feature back properly because I think the pieces to do it right now exist and didn't before.

The short version: instead of resurrecting the Python 2 dom0 plugin, add a container collector to the new Rust xen-guest-agent, publishing container state through XenStore the same way the agent already publishes IPs and OS info.
XO 6 reads it like any other guest metric and renders a Containers tab on the VM view. No dom0 code, no SSH from the hypervisor into guests, no network path needed between XO and the guest at all.

The old design required user interaction/modification of dom0 (the worst place for anything needing a modern crypto stack), it needed dom0→guest SSH credentials (a trust relationship plenty of admins don't want), and it polled over the network (breaks in segmented setups).

The new xen-guest-agent dodges all three by design. It's already built around pluggable collectors (OS, kernel, network, memory today) publishing to XenStore, and the README explicitly says you want it "to become more largely useful" with the collection scope still stabilizing and proposals welcome. A containers collector seems like a natural fit:

• The guest publishes what it chooses — opt-in, auditable, no credentials held by anyone
• Works across any network topology since nothing needs to reach the guest
• All the code lives in actively-maintained projects (the agent + xo-server/xo-web)
• And it generalizes for free: the same collector could report "this VM is a k8s worker, kubelet healthy, 14 pods" — giving XO a light infra-level view of Kubernetes nodes without pretending to be a k8s dashboard.
• Complements the existing k8s recipe rather than competing with kubectl/Lens.

AI assisted UI Mockup:

Example draft Schema - the real version belongs in the agent's RFC doc discussion. But to make it concrete:

data/containers/version      = 1                  # schema version
data/containers/runtime      = "docker 27.5.1"    # or podman/containerd
data/containers/updated      = 1755640051         # unix ts of last refresh
data/containers/summary      = {"running":4,"exited":1,"paused":0,"images":14}
data/containers/list         = <compact JSON array, one object per container:
                                id (12 chars), name, image, state, ports,
                                cpu_pct, mem_bytes, started_at, health,
                                compose_project?>
data/containers/k8s          = {"role":"worker","cluster":"...","pods":14,
                                "kubelet":"healthy"}   # only if applicable

Practical guardrails baked in: summaries not full docker inspect dumps, a size cap on list (truncate + flag if a VM runs hundreds of containers), refresh every 30–60s with writes only on change, and the whole collector behind a feature flag since it needs docker socket access the base agent doesn't. A typical VM's payload is a few KB.
Lifecycle actions (start/stop/restart) would be nice, but read-only visibility is already most of the value and keeps the security story dead simple.

Whatever happens with this proposal, what could be done to update/modify the "Docker in XCP-ng" wiki page?
A "currently broken with modern guests, see topic 6845" banner, or the whole thing just be pulled would be ideal...

I suppose I'm wondering if there's any interest out there?
Would you use this?
Anything missing or wrong in the approach?
Is anything like this already on the table or in the works? (The guest agent's own README hints at broadening its collection scope, so maybe this is already somewhere on a roadmap — happy to be told I'm re-imagining the wheel.)
Does the agent seem like the right vehicle, or would you approach this differently?

P.S
Thank you to the Vates team, and community members for XCP-ng and XO and for keeping them free and open source and awesome and this community is exactly why this ecosystem is worth contributing to.