Updated October 19, 2026. We first published this in June, when it was a small standalone dashboard. It is now the XenServer side of DTR Vantage, and some of what we wrote then turned out to be wrong. This version has screenshots from the current build and says what we changed our minds about.
Most XenServer environments we walk into have the same monitoring story: a bash script that emails a Markdown report once a day, plus XenCenter open on someone’s desk. That’s not nothing — the bash report is often genuinely good — but it stops at one host or one pool, the email gets filtered into a folder nobody reads, and “are all our pools healthy right now?” still means logging into each one to check.
So we built a dashboard that turns that report into a live, multi-pool view. Here’s what it does now, and the lessons that shaped it.
What we still optimize for
We wrote the constraints down before writing any code, because in this space they matter more than the features. Most of them have held:
- No agent on the hosts. XenServer’s Dom0 is opinionated about what gets installed there, and rightly so. The health check is a script the dashboard copies to the pool coordinator over SSH and runs there; when a newer build ships a newer script, its SHA-256 changes and the next collection copies it again. Nothing runs on the hosts between collections.
- No passwords kept for monitoring. Collection uses an SSH key the pool already trusts. When you enrol a pool, you can type the root password once so the dashboard installs its key; the password is used for that and discarded, never written to disk or logged.
- Works without the internet. Many XenServer estates can’t reach it. The installer carries everything it needs, and the dashboard contacts nothing outside your network unless you switch a cloud option on.
- Honest about what it knows. When data is old, or could not be read, the page says so instead of showing the last good answer. This one turned out to need far more work than we expected (more below).
- Your directory, not ours. Operators sign in with their Active Directory accounts, and AD groups map to three roles: viewer, operator and administrator.
The one we dropped was “read-only, always”. More on that below too.
How a collection works
Every 15 minutes by default (per pool if you like), the dashboard reaches out to your pools, runs the health check, brings the results home and turns them into the views your team uses. Click a step to follow it.
The dashboard wakes on a fixed interval (15 minutes by default, or a pool’s own) and starts a collection. Collect now runs one at any time.
Lesson one: “healthy” and “we read it” are different questions
The first version had one colour per pool. If a coordinator stopped answering, its card stayed green — the last report had been healthy. Green meant “nothing wrong was seen”, which is not the same as “we looked”.
Now every pool answers both, in separate columns. Health is what the last report observed. Collection is how many hosts have a current reading. When a report is older than twice the collection interval, health reads Unknown, with the last known verdict beside it, never the old colour. Problems sort to the top, and a pool expands in place to its hosts.
Lesson two: Dom0 is not the host
The health script runs in Dom0, XenServer’s control domain. So its memory, load average and disk figures describe Dom0 — a small VM — not the physical server. The first version showed them as the host’s, so a busy 256 GB host could look idle, and a control domain under pressure could look like a full host.
Now the two are kept apart. Host memory is the physical servers’, read through the XenServer management API and summed across the pool, with the busiest host named beside it. Dom0 memory, load and system disks are labelled as Dom0’s. VM storage counts each repository once and tells shared from local, and ISO libraries are never flagged for being full. Physical CPU time needs XenServer’s performance data, which we don’t read yet. So there is no CPU column, and the page says why rather than guessing from a load average.
From one view to a page per pool
Each pool has its own page. It opens on a verdict box listing the reasons, and each reason links straight to the host, repository or finding it names. Tabs cover hosts, VMs, storage, networks, activity and settings, and two labels say how old the inventory and the health report are. Trends charts findings, the verdict and each host’s resources over the past month, so you can tell “getting worse” from “just today”. Notifications brings every pool’s own alerts together with readable names, alongside the events from the health reports.
What we changed our minds about: read-only
In June we wrote that the dashboard would never start a VM, migrate a workload or patch a host. But keeping XenCenter open beside the dashboard was the problem we set out to fix, and a read-only view only solved half of it.
So there is now a XenServer console, licensed separately; with monitoring alone, the dashboard still only reads. It covers the day-to-day of XenCenter in the browser:
- VMs: power, snapshots, settings, and new VMs from templates.
- Pools: storage repositories and VLAN networks.
- Host updates: one host at a time, coordinator first. Each host is emptied of VMs, updated, rebooted or has its toolstack restarted, and brought back.
It also opens a VM’s screen right in the page, with Remote Desktop and SSH in the browser alongside. The inventory tree follows the pool’s own change events, so a VM powered on elsewhere turns green in seconds rather than at the next collection.
We put limits on it. The pool’s management credential is stored encrypted on the dashboard server and never sent back to a browser. The coordinator’s certificate is pinned the first time, and a changed one is refused until an administrator accepts it. Actions that destroy data, like deleting a VM or reverting a snapshot, need an administrator. Every action is a task with its own log line, and is audited with who did it.
Active Directory sign-in that just works
Getting sign-in right was the hardest part of the first version, and it still is the part people notice least when it works. Modern Python runtimes, hardened directory settings and strict certificate checks each broke approaches that “should” have worked and that most online guides still recommend.
So the sign-in is built to be resilient rather than textbook. It binds to the directory over encrypted connections that hold up on current systems, and reads group membership in a way that works even in locked-down domains. It checks certificates fully, while still letting you connect by IP address or host name. Windows single sign-on through IIS is there for sites that want it.
Installation
The dashboard runs on a Windows server beside your pools, not inside them. You install it with one setup program, and a wizard asks what to install and how the site should be reached (IIS in front, with HTTPS). Then you enrol your first pool from Manage pools. Updates come from the dashboard’s own settings page. Your configuration, pools, sign-in settings and history are kept across them.
What it still doesn’t do
Health comes from collections, every 15 minutes by default. The console’s inventory is live, but the health verdict is not a sub-minute alarm. There are no physical CPU graphs yet, since that needs XenServer’s performance data, which is next on the list. Alerts show in the dashboard; if you want a phone to ring, point your existing alerting at it.
You can click through all of it in the live demo, which runs on a sample estate, or try it on your own pools. And if you’re running XenServer and doing this the manual way, we’re always happy to compare notes.