@nathanael-h This is awesome — genuinely didn't expect to go from "is there any interest?" to screenshots of a working Containers tab in under two months. Thank you (and thanks @TeddyAstie for the architectural context — the vsock/pv-channel angle makes a lot of sense as the "someday" answer).
I'll build and play with the later today and will report proper back with test results, including whether I can reproduce @acebmxer's multi-VM fingerprint issue. (As an aside, I really only use docker - if there's any guru's running podman out there that want to give this a crack and provide some feedback, this is the place to do it ).
There's a lot to like about the SSH shortcut. No dom0 involvement and nothing to install in the guest makes for lower setup friction than what I originally proposed, honestly. And because it talks to a socket path rather than baking Docker knowledge into an agent, it ends up runtime-agnostic almost by accident — which I think fairly answers Teddy's "one size fits all" concern about my collector idea, so point conceded there It also means the crypto-rot failure mode that killed xscontainer (fossilized paramiko in dom0 arguing with a modern guest sshd - btw have the old packages been or plan on being removed from dom0?) structurally can't recur, since XO's SSH stack gets updated along with XO itself. And full socket access clearly made lifecycle actions and logs come essentially for free — that's already beyond the read-only v1 I'd imagined.
IF ( - big if) this iteration makes it eventually, I'd love to see the docs (or UI) recommend a dedicated unprivileged user for XO's access, a rootless socket where possible, and ideally a forced-command/restrict entry in authorized_keys that limits the key to socket forwarding only — I.E if the connection form could even just nudge people toward that pattern, the security story gets much more comfortable. Related to that, a read-only mode toggle would be valuable (although I realise the irony that if a bad actor already has access to XO they effectively have the keys to the castle and a read-only option is moot - perhaps you could weigh in on this idea?); the biggest win imo is just the basic visibility (as I'd imagined in a v1 release) and I imagine some users would happily take visibility while being nervous about handing XO stop/delete power over their containers, and read-only also shrinks what a compromised XO could do with the stored keys. Two smaller ones, mostly for docs/expectations: XO now needs network reachability to every monitored VM, which is fine for homelabs like mine but a real limit in segmented environments (sorry Networking Team in advance!); and the per-VM connection form is fine at my scale, though at many-VMs scale some way to apply a credential across tagged VMs might eventually be wanted (later down the track - food for thought for the XO6 UI and handling of SSH keys maybe?).
One question I have relates to surfacing data freshness and connection state: how quick would the UI respond if the docker socket was stopped or ssh connection was terminated (or container in a restarting state)? Would it be feasible to add something like "last refreshed Xs ago" / "disconnected since..." if not already so an empty container list could be distinguished from a dead connection (will try and test this later as well and determine how quick it reacts ) NinjaEdit: Just double checked the screenshots - Already implemented - nice work
Thanks again for actually building the thing — this is exactly the "community raises it, Vates runs with it" loop that keeps me on this stack.
should we read this experimental SSH approach as stopgap — something to validate the feature and UI now — with the longer-term intent being one of the no-network transports Teddy described (vsock/pv-channel bridging of the socket) once the plumbing exists in a future XCP-ng? Asking because the nice property of this design is that the XO-side code and UI shouldn't really care about the transport: if the answer is "yes, SSH now, vsock later," then everything built here survives the swap and the credential/network concerns above largely resolve themselves over time. If instead SSH is intended as the permanent design, the hardening points matter more. Either answer is fine — just keen to know which way to aim feedback.
(Also, this also opens up the possibility of having containers visible across a whole Cluster, similar to how VM's are now viewed, and a whole host of options for container labels/tags and smart(er) backup features! OMG!)
