install_xen_orchestra v0.7.2 — twelve templates, and the builder can now use XO's own API
Since the v0.5.0 post the template library has gone from one distro to twelve, and it picked up a second way of talking to the pool. Everything from v0.5.0 through v0.7.2, in one place.
Templates: twelve buildable, three still to come
v0.5.0 shipped with Debian 13 and I asked here which distros to do next. That list is now:
Debian 12, 13
Ubuntu 22.04, 24.04, 26.04 LTS
AlmaLinux 8, 9, 10
CentOS Stream 9, 10
Fedora 43, 44
Rocky Linux 8/9/10 are the only rows still marked Coming Soon... in the menu.
Every one of these is a row in the catalogue table rather than new build code, which is what I said in the v0.5.0 post I was aiming for. Each image did get read individually rather than assumed to match its neighbour — default user, disk size, kernel type, partition table — because those differ inside a family. Ubuntu 22.04 expands to 2.2 GiB and 24.04 to 3.5 GiB, so copying one figure across the family would have inflated every VM cloned from the smaller one.
Two things that had to be solved along the way and now apply to every image:
qcow2 images import. Debian publishes raw; almost everyone else publishes qcow2, so the builder converts before importing.
The shipped password actually works. The RHEL-family and Fedora images declare lock_passwd: True for their default user, and cloud-init re-locks that account on every boot — so the password the build set was already locked by the time a clone came up. The build now drops a file in /etc/cloud/cloud.cfg.d turning that off. Delete it once you've put your own SSH keys on. Key auth was never affected.
Arrow keys in the template menu now skip the Coming Soon rows instead of stepping through them.
The builder can now go through XO's API instead of SSH to dom0
Template building has always driven xe over SSH to the pool master, which means having the pool master's root password to hand. Everything it does that way, XO exposes over its own API — create the VM, import the disk, build the cloud-init drive — so v0.7.0 added that as a second path.
Which one makes sense depends on where you run it from. If you installed with --deploy, this repo is sitting inside the XO VM and that's where you run --update from, so XO is on localhost and you already have an API token in xo-config.cfg for the pre-update task check. Same token, no root password. Run it from your workstation against a pool with no XO on it yet and none of that is true, so SSH stays.
TEMPLATE_BUILD_METHOD picks:
auto # default — API if it's reachable and authenticated, else SSH, and it says which and why
api # API only, no fallback
ssh # exactly what it did before
The choice is made by a preflight check before anything gets created on the pool, so a fallback costs you nothing but a different password prompt. On the API path the image streams from its mirror straight into XO without being staged to a file, and XO builds the cloud-init drive itself — so no ISO writer needed on the machine you're running from.
Two new config keys: XO_API_TOKEN and XO_URL. XO_API_TOKEN replaces XO_TASK_CHECK_TOKEN in name only — the old key is still read, so an existing config keeps working untouched. XO_URL can be left unset on the XO VM itself, and falls back to PUBLIC_URL if you've set that.
--deploy fixes
The appliance now gets the XCP-ng guest tools. A deployed VM had no guest agent at all, so the XO it was itself hosting couldn't report its IP, memory or disk usage, and couldn't shut it down cleanly. It ran fine while looking half-blank in the very interface it served.
It now boots UEFI, not BIOS. Nothing was ever setting the firmware parameter, so a VM from --deploy and a VM cloned from a --build-templates template came out of the same script with different firmware. It's probed from the disk now, same as the builder does.
The temporary deployment SSH key is actually removed. It wasn't being deleted, leaving a working key on the VM.
Progress bars
curl --progress-bar redraws the whole line every update and leaves the cursor sitting in it, which over SSH is a cursor visibly scribbling back and forth instead of a bar filling up. All four transfers now draw a bar that doesn't repaint, including the one that stages the image on the pool master — which is the longest step of a deploy and was the one people would actually be watching.
Also
Templates get sensible platform settings instead of inheriting them from the scaffolding: vga=std with 16 MiB video memory (the stock 4 MiB cirrus is what leaves the console at 640x480), viridian off (it's Hyper-V enlightenment, meant for Windows), and cores-per-socket matching the vCPU count.
Checksum verification works for every origin now. AlmaLinux, CentOS Stream and Fedora would each have 404'd on the wrong filename and imported unverified with a warning.
Debian 11 and Ubuntu 22.04 are deprecated with dates on them, and the menu says so rather than the row silently vanishing one day.
The README's menu screenshots no longer need a horizontal scrollbar on GitHub.
353 unit tests, and CI smoke-tests the install on 10 distros.
Repo: https://github.com/acebmxer/install_xen_orchestra
Changelog: https://github.com/acebmxer/install_xen_orchestra/blob/main/CHANGELOG.md
Templates doc: https://github.com/acebmxer/install_xen_orchestra/blob/main/docs/templates.md
