Skip to content
Documentation ReferenceChangelog

Changelog

Project-level changes across all XCP-hl repositories, with the issues they resolve. Per-release component versions live in the Release Matrix.

Generated release notes

v8.3-ce50 · 2026-10-27

Stable · Components:xcp-ng-ce-iso v8.3-ce50, xolite-ce v0.21.0-ce35, xoa-proxy v0.1.2.7

Pull request titles are shown in English.

Earlier project changes

September 2026

The deployed XOA VM is named XOA-hl, fixes #97

Deploying the XOA-hl appliance from XO Lite produced a VM called xoa-almalinux, the internal Packer build name, not a product name. XO Lite does not rename what it imports: VM.import keeps the name-label carried by the XVA, which is exactly the builder’s vm_name. The build now sets vm_name to XOA-hl, in both build-xoa-hl’s setup-xoa-builder.sh (manual builds) and the orchestrator’s xoa-vm-agent (the daily pipeline that publishes the images).

Because Packer derives the XVA filename from vm_name, the release asset is renamed with it, xoa-almalinux.xva becomes XOA-hl.xva. Nothing resolves that asset by name: XO Lite’s deploy button and the agent’s release check both pick the first .xva / .xva.gz asset on the newest xoa-image-* release, so already-published images keep working and no ISO needs reissuing.

The name applies to images built after this change. Appliances already deployed keep the old name and can be renamed in XO; orchestrator hosts with a /etc/xcp-orchestrator/build.config from before this change keep their own VM_NAME (deploy.sh never overwrites an existing config) and need that key updated by hand.

Default ISO storage, closing #2 and #46

A fresh XCP-ng host has nowhere to put installer ISOs: no ISO SR exists and creating one is a manual xe sr-create against a directory you have to make yourself. XCP-hl now reserves a 20 GB partition at install time, formats it ext4 as xcphl-iso, mounts it at /var/opt/xen/xcp-hl-iso, and registers it on first boot as an ISO SR named XCP-HL ISO library, ready to upload to from Xen Orchestra.

This sets XCP-hl’s minimum disk at 100 GB: ~41.5 GB of system partitions, 20 GB of ISO library, ~38.5 GB left for VM storage. Below that the reservation is skipped rather than squeezing VM storage to a few GB, and the disk is laid out exactly as stock XCP-ng would.

Issue #46 asked whether XCP-ng’s upload endpoint could be given an ISO-specific route. It turned out not to need one: PUT /import_raw_vdi is a generic raw-VDI import that XO 5 already drives through Import → Disk, and the only thing missing was an ISO SR to import into. No new endpoint was added.

The partition is created by the installer, so it applies to fresh XCP-hl installs only. Hosts installed from stock XCP-ng that later add the XCP-hl repositories are never repartitioned, and upgrades keep the existing partition rather than recreating it.

Delivered by patching host-installer inside install.img at ISO build time rather than shipping a forked host-installer RPM. See xcp-ng-ce-iso.

August 2026

Release matrix states the exact package shipped, towards #15

The Release Matrix recorded only a release tag per component. For xoa-proxy that was not enough to identify what a host is running: the tag maps to a version, but the RPM release field carries the CI run and source commit, and the two oldest rows carry a v-proxy-automated-* build-run tag that states no version at all.

Each per-ISO row now shows the package as rpm -q prints it (xoa-proxy-0.1.1.8-55.gc525575.static.x86_64) under a version that links to its release page, for the ISO, xolite-ce and xoa-proxy alike. Existing rows were backfilled from the published release assets, and the v8.3-ce3 / v8.3-ce4 xo-lite upstream was corrected from 0.22.0 to 0.21.0 to match the RPM those builds actually ship. The orchestrator records the new field on every build (xcp-orchestrator shared/src/github.rs).

July 2026

XOA VM image releases moved to build-xoa-hl, fixes #22

The XOA-hl VM (xoa-image-<date>-<sha7>, asset xoa-almalinux.xva) was published on xoa-hl, the repo that builds the software, mixed in with its RPM releases. It is now published on build-xoa-hl, the repo that actually builds the image. The orchestrator’s xoa-vm-agent creates the release there, and XO Lite’s deploy button resolves the newest image from that repo.

The mixing had a concrete cost: releases/latest on xoa-hl resolved to an image release with no RPM asset, breaking the RPM lookup in build-xoa-hl/scripts/setup-xoa-builder.sh, now fixed to scan for the newest release that actually ships an RPM.

Image releases published before the move stay on xoa-hl so already-shipped ISOs keep resolving them; the Release Matrix links each entry to the repo that hosts it.

Release matrix records XOA versions, fixes #13

The Release Matrix now has a dedicated XOA appliance releases table recording each published VM image (xoa-image-* release on Vagrantin/xoa-hl), the xoa-hl software version it contains, and the upstream Xen Orchestra version it was forked from. The per-ISO table also dropped a never-populated xoa-hl column, the appliance is resolved at deploy time and versions independently of the ISO.

XOA-hl edition complete, fixes #1, #6

Xen Orchestra HomeLab Edition is now built from source, packaged, and deployable end to end:

  • xoa-hl builds XO 5.113.2 (the last XO 5.x release) from a pinned upstream commit and patches the UI: the license-gated menu entries (Hub, XOA, Proxies, XOSTOR) and the no-support banner are hidden (patches/menu-hide-items.patch).
  • build-xoa-hl packages it into a self-configuring XVA appliance via Packer on XCP-ng.
  • XO Lite’s deploy view now offers XOA HomeLab (latest build) as a deploy image option, resolving the newest agent-built XVA from GitHub releases at deploy time (xolite-ce commit 6abd43f, 2026-07-14).

Release publication automated, fixes #4

Versioning and release notes are now derived automatically in every pipeline:

  • xolite-ce and xoa-proxy derive the release tag and RPM version in CI (xolite-ce 7b2e4d4, xoa-proxy 9582718); xoa-proxy releases use GitHub’s generated release notes, xolite-ce and the ISO ship structured release bodies with source versions and verification steps.
  • The ISO build is dispatched by the orchestrator with exact component release tags pinned as workflow inputs, eliminating stale-RPM races (xcp-ng-ce-iso 68f211d).
  • Every ISO release is recorded in the Release Matrix.

June 2026

Documentation website CI/CD, fixes #5

The project website (this site) is built with Jekyll and deployed to GitHub Pages automatically on every push to main of xcp-hl (.github/workflows/pages.yml), making it the single source of truth for project status, including the data-driven release matrix.

v8.3-ce9 released

  • xolite-ce v0.21.0-ce6: upstream xo-lite pinned to 0.21.0, the last known-good release (0.22.0 and 0.23.0 broke the build), through the UPSTREAM_TAG file.
  • xoa-proxy v0.1.1.x: simpler RPM versioning (.static release suffix) and automated, categorized GitHub release notes.
  • Consistent artifact naming: xcp-ng-8.3-ceN.iso + .iso.sha256 + .iso.sha256.asc, published as xcp-ng-ce-iso GitHub Releases.

May 2026

GPG key model implemented, fixes #3

GPG signing is harmonized across all build pipelines using an offline master key + two signing subkeys model: one subkey signs the RPMs (xo-lite-ce, xoa-proxy), the other signs the ISO checksum file. The public key is published on keys.openpgp.org and verification steps ship in every release body. See GPG signing for details. A follow-up refinement (one key per module) stays on the roadmap.

First public release, v8.3-ce alpha2

  • First usable release.
  • Deploys XOA from the Vates image, Ronivay’s image, or a custom URL.
  • GPG: offline master key + dedicated RPM and ISO signing subkeys. Public key published to keys.openpgp.org.

April 2026

First build, v8.3-ce

  • XO Lite patched: community deploy endpoint, read-only credential fields.
  • xoa-proxy Rust server bundled: HTTP/HTTPS, gzip streaming.
  • ISO assembled from upstream XCP-ng 8.3 with a community RPM repository layered on top.
  • GPG key infrastructure (4096-bit RSA, single key RPM-GPG-KEY-xcp-ng-ce).
  • GitHub Actions CI/CD pipeline: RPM build → ISO build → GitHub Releases.
Release matrixRoadmap