acebmxer

install_xen_orchestra v0.9.0 — install optional server plugins with --custom-plugins

Since the v0.7.2 post there's been a safety-net release (v0.8.0) and a new feature (v0.9.0). Everything from v0.8.0 through v0.9.0, in one place.

v0.8.0: VM snapshots before update/rebuild, and every RHEL template is now buildable

--update and --rebuild now take a normal XO API snapshot of the XO VM itself before touching anything, on top of the existing file backup — it shows up in XO's own UI under the VM's Snapshots tab like any other. Old ones get pruned automatically (keeps 3, or 14 days, whichever you set) so they don't pile up and trip XO's own Health-view warnings. This only works when XO itself is a Xen guest; bare metal just keeps the file backup as before.

Also new: a --status command that gives a read-only summary — version, how far behind master, service state, TLS cert expiry, disk/swap, backup and snapshot counts — and a --list-backups to see what's there without going through a restore. TLS certs now get a warning once they're under 30 days from expiring, wherever that check would previously only surface as a failed connection.

Rocky Linux 8, 9 and 10 dropped their "Coming Soon..." tag and build now — same tpl_prep_rhel script the AlmaLinux and CentOS Stream rows already use, since it's the same family. Every row in the template catalogue builds something now.

Rest of v0.8.0 was a security hardening pass — checksum-verifying the Node.js download, no more passwords on the command line for the XO Proxy helper, tightened file permissions on config.toml and the swap file — worth a look at the CHANGELOG if you're running this on anything you care about.

v0.9.0: --custom-plugins — install optional xo-server plugins with one command

XO has a plugin system (xo-server-auth-ldap, xo-server-load-balancer, that kind of thing) but nothing installs one for you — you're expected to drop it under node_modules by hand and restart the service. --custom-plugins (new menu entry too) does that part: pick a plugin, it gets copied to /usr/local/lib/node_modules/<name> — outside /opt/xen-orchestra, so --update's rebuild never touches it — and xo-server restarts to pick it up. Run it again and anything already installed shows pre-checked; uncheck to remove, check something new to install, leave one checked to refresh it if this repo's copy has changed since. Configuration itself still happens the normal way, in XO's own Settings > Plugins.

Two plugins ship to start:

• xo-server-nanokvm — power control for a host fitted with a Sipeed NanoKVM, over its REST API.
• xo-server-host-power-manager — powers an extra pool host on when CPU or memory gets tight, and powers it back off (evacuated first, same path as XO's own maintenance mode) once it isn't needed. Power-on can go through NanoKVM or XO's built-in iLO/DRAC/Wake-on-LAN.

Docs: docs/custom-plugins.md

The host-power-manager plugin got the most testing this round, and threw up a few real bugs against a live pool: saving its settings while it was already running silently killed every rule's timer until the next xo-server restart, its CPU/memory numbers disagreed with XO's own dashboard because it was excluding the managed host from the pool total, and there was no way to build a CPU-only or memory-only rule since both thresholds were required. All three are fixed, and power-off is now HA-aware — it defers to XAPI's own failover check and just leaves the host running and retries later rather than forcing an evacuation that would break your HA plan.

Repo: https://github.com/acebmxer/install_xen_orchestra

As always, let me know if you try either plugin out or hit anything.

@lem2405 said:

@acebmxer Excellent! Thanks a lot!

Welcome, enjoy.. Please let me know if you have any issues or suggestions to help improve.

@lem2405 said:

@acebmxer Is there a way to make the update feature completely unattended so it can be configured to run as a cron job?

Regards

Sure... Make sure you configure xo-config.cfg correctly. ./install-xen-orchestra.sh --update. It would only prompt for sudo passwor d.

Available Functions

Function	CLI Flag	Description
Deploy	--deploy	Create a Debian VM on a XenServer/XCP-ng pool and install XO into it
Build Templates	--build-templates	Build cloud-init VM templates on a XenServer/XCP-ng pool
Install	--install	Fresh install of Xen Orchestra
Update	--update	Update existing installation (with backup)
Restore	--restore	Restore from a previous backup (verified for completeness first; add --list-backups to just list them)
Rebuild	--rebuild	Fresh clone + clean build, preserves settings
Reconfigure	--reconfigure	Apply config changes without rebuilding
XO Proxy	--proxy	Deploy XO Proxy to a Xen pool master
Adjust Memory	--adjust-memory	Raise the heap memory allocated to the xo-server process
Status	--status	Read-only health report: version, service, TLS cert, disk/swap, backups/snapshots, git state
Edit Config	(menu only)	Open xo-config.cfg in your preferred editor
Rename Config	(menu only)	Rename sample-xo-config.cfg to xo-config.cfg

Running without flags launches an interactive menu. All flags also work directly:

./install-xen-orchestra.sh           # interactive menu
./install-xen-orchestra.sh --update  # run update directly
./install-xen-orchestra.sh --help    # show all options

@julienXOvates

Yes verified links working correctly now.

Vates tech responded to my ticket - Ticket#7762089 stated there was patch to apply to my XOA. After it was applied the rep stated to reboot XOA..

From then XOA would not connect to either remote proxy with error about unknown state (logs in ticket) XOA keep running into OOM issues after about 5 min idle trying to reconnect to remotes... Multiple reboots of xoa or proxy would not let them reconnect or memory issue to stop...

I had issues trying to revert back to previous snapshot taken during on of the upgrades... Eventualy got to to revert back to 6.8.1 proxies reconnected instantly...

v0.8.0–v0.9.1 — multi-user accounts, self-update, built-in HTTPS, and date ranges. Three releases since the last update, so bundling them here.

Date ranges. Collections, extractions, findings runs and the support package can now be scoped to a window instead of always covering the whole bundle — last 24h/7d/30d, since last reboot, or a custom range. XO's own routes still have no date filter, so the first download is unchanged size — the range only narrows what gets kept and reported afterwards.

Redact on demand. A collection no longer has to redact immediately with whatever rules happen to be on at that moment. There's now a checkbox to store the raw bundle only, and a "Redact now" button on the card afterwards using whichever rules are switched on when you press it.

Multiple user accounts, roles, and an activity log. This was on the "what is coming" list in the first post and it's in now. Any number of accounts, three roles — admin, operator, viewer (read-only, but can still download what's already stored) — and an Activity page logging logins, settings changes, and job runs.

Optional 2FA. Per-user TOTP, off by default, each account turns it on for itself. QR code setup, backup codes.

Self-update from the UI, opt-in and off by default. Checking needs nothing extra; applying an update needs the Docker socket mounted in explicitly, since that's effectively host root, so it's a separate deliberate step — uncomment the socket mount and group_add block in docker-compose.yml, and it needs its own .env file (just DOCKER_GID=..., next to docker-compose.yml, not the same file as xcp-pulse.env) or docker compose up -d fails with unable to find group. .env.example has the one-liner to generate it.

Built-in HTTPS, no reverse proxy required. Bundles nginx into the image to terminate TLS — self-signed cert on first start, or upload your own from Settings. A reverse proxy still works fine too.

A user manual in the app itself, under /help — no need to leave XCP Pulse or check out the repo to read how something works.

Fixed

• The account-requirements note from the first two posts was wrong in a way I only found by testing it properly: export:logs — the privilege log downloads actually need — isn't in any built-in XO role, but it can be granted through a custom role. "Test connection" was reading a catalogue that can't tell you that, and told every restricted account it needed full admin regardless. It now actually probes the download endpoint, and the docs walk through creating the custom role via three REST API calls (no UI for it yet on either XO version).
• A real concurrency bug: the shared SQLite connection wasn't locked across fetches, only execute, so two requests landing close together could crash a page reading jobs — reproduced it under the test suite's own concurrency test.
• Base-OS CVEs patched in the image build (perl-base, libc6, others); CI now runs a Trivy scan on every push.

Still not fixed: the truncated-download-behind-a-reverse-proxy issue from the last post. Haven't found the actual cause yet. Also looking for anyone who can test against a remote proxy in a lab setup. Also open to any other suggestions, features, improvements, UI changes, etc...

If any chance someone on Vates would test on their own time. Things like the support bundle and or the logs themselves are not being manipulated in any unwanted ways (for Vates or the project)

https://github.com/acebmxer/xcp_pulse

v0.7.0 — findings, category extraction, and a Vates support package.

Since the last update, log collection has been through a few fixes and gained three new pieces built on top of it.

Findings, from two sources. A new Findings page reads the XO API (messages, alarms, tasks, missing patches, backup/restore runs) and also scans a collected bundle for storage failures, multipath issues, XAPI exceptions, HA fencing, OOM kills and clock skew — six log-based rules in total now. When both reports describe the same incident (matched by condition and, if both are timestamped, within an hour of each other) each finding gets a small "confirmed by" badge instead of showing up as two unrelated entries.

Individual log categories, pulled out of a bundle already on disk instead of downloading again — XAPI, storage, audit, security, kernel, HA, xenstore, RRD, network, system. Tick categories on the Collect form before collecting, or against an already-stored bundle afterwards.

A Vates support package. One .tgz — redacted bundle, findings (MD + JSON), redaction report, inventory, and a manifest of what's inside and what was masked — instead of downloading each piece separately.

Dashboard status panels now show findings severity, how many redaction rules are off, storage used, and recent job activity at a glance.

Known issue — still unsolved

The truncated-download-behind-a-reverse-proxy bug from the last post is not fixed. logs.tgz has no Content-Length (XCP-ng builds it on the fly), and on my own Nginx Proxy Manager deployment the proxy's connection to XO intermittently closes before the last chunk arrives. Two things tried, neither fixed it:

• proxy_buffering off / proxy_set_header Connection "" — reduced how often it happened, didn't eliminate it. Identical config, run twice back to back, produced one good download and one truncated at the same offset as before.
• Suppressing httpx's Accept-Encoding: gzip, deflate header (it was asking the proxy to transport-encode an already-gzipped file) — same result, only reduced frequency, not shipped since it doesn't actually fix anything.

proxy_http_version 1.1; broke the proxy outright when I tried it, for a reason I don't understand — so that's not the next thing to try either.

What XCP Pulse now does about it: reads the archive in streaming order and keeps whatever it read before the stream broke, rather than losing the whole analysis to the last few missing bytes, and says on the report when it ended early. If a collection tells you the bundle ended early, the honest advice is to retry it — not that it's fixed. Documented in docs/installation.md in case someone with more insight into the Nginx/httpx side of this has a fix.

Also fixed since v0.6.0

• The restricted-account warning on the Collect page was showing on every connection, including admin ones — wrong template condition, not a real permission check. Fixed.
• The default collection no longer downloads the XAPI audit trail unless you ask for it — xen-bugtool already includes it in the bundle, so it was 770 MiB of duplicate data on every run. Default collection is now the bundle only, ~870 MB / ~3 minutes.
• XO's /messages and similar routes were being limited from the oldest end, not the newest — a pool with a lot of history could return findings from a month ago and miss everything recent. Now filtered by time window server-side instead.

https://github.com/acebmxer/xcp_pulse

I have received a very long update back from Veeam on my backup issues....

There appears to be another user with similar setup / issue not sure if that user is the OP this post specifically...

Hello,

Thank you for your patience. The QA team has finished the analysis, and I am going to outline the details as below:

1. CBT Inconsistency Issue

Whenever you see the Warning about CBT showing:

2026-08-16 17:37:27.459 00079 ERROR | [XenRpcClient]: Failed ListChangedBlocks. Error: [Task 291af3d7-28c1-15a9-7f13-c6a1a12283e9 (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated].

We can go to the previous run and see that we get reports that the CBT of the previous snapshot is inconsistent and thus removed by XCP:

2026-08-16 09:54:34.120 00004 ERROR | [XenBackupManager]: Failed to retain the data for the snapshot 5a17fb31-2616-4e72-a85c-e235883c8c91
Veeam.Vbf.Common.Exceptions.ExceptionWithDetail: [Task 39c0f25f-e811-ee45-1b0b-e4a9ca9839ae (Async.VDI.data_destroy) failed: . VDI_NO_CBT_METADATA. OpaqueRef:a005d328-6da0-b8b7-34ef-0607ed44c2ed

The team has been reviewing and testing, and this is what they see. We send the request for the snapshot to be created, and it is sent to the coordinator: xcp-ng-vyadytkn

Aug 16 09:50:08 xcp-ng-vyadytkn SM: [1555017][MainThread] vdi_clone: introduced VDI: OpaqueRef:a005d328-6da0-b8b7-34ef-0607ed44c2ed (5a17fb31-2616-4e72-a85c-e235883c8c91)

CBT shows as open and reading fine:

Aug 16 09:50:08 xcp-ng-vyadytkn SM: [1555017][MainThread] ['/usr/sbin/cbt-util', 'set', '-n', '/var/run/sr-mount/7911c9c5-5f20-01e1-8b8d-39c6a98a2704/5a17fb31-2616-4e72-a85c-e235883c8c91.cbtlog', '-f', '1']
Aug 16 09:50:08 xcp-ng-vyadytkn SM: [1555017][MainThread]   pread SUCCESS

But look at how on xcp-ng-host2 the CBT gets marked as inconsistent by XCP, even though it's open and reading:

Aug 16 09:51:05 xcp-ng-host2 SM: [1683689][MainThread] Changed Block Tracking metadata is inconsistent for disk 5a17fb31-2616-4e72-a85c-e235883c8c91.

The Breakdown:

• xcp-ng-vyadytkn was the coordinator—the one we talk to, who then passes everything around to the hosts.
• xcp-ng-host2 was the host that the VM resided on at that time.
• xcp-ng-host2 is marking the CBT as inconsistent and deleting the snapshot CBT log, which means we cannot reference it on the next run. We do not see anything else interacting with the CBT besides that host.

This matches exactly what we see with another client running the same setup. The team successfully replicated the environment, which is configured as follows:

• VM storage is NFS.
• The VM is running on a host that is not the coordinator.

They have been able to reproduce this behavior occasionally, and the working theory is that the VM host keeps its own tracking separate from the coordinator. Part of the backup process requires the VM host to issue a pause/resume via a process called tapdisk. When it resumes, it pushes a data cache (likely inside the NFS cache), overwriting the CBT reference held by the coordinator server. It acts as a race condition—whoever pushes the CBT data last wins. If the VM host pushes last, it breaks what the coordinator is sending.

Next Steps for CBT:
The team is working to raise this issue directly with Vates so they can address the race condition. We ask that you also open a Vates ticket if possible to help draw more attention to the bug. We are trying to find ways to code around this race condition in the future, but there are currently no ETAs or guarantees.

---

2. Synthetic Full Failures (Delilah_ArcFS01)

In addition to the CBT bug, the team discovered a separate issue. Recently, the synthetic fulls for Delilah_ArcFS01 have been failing. This appears to be related to the NFS repository:

[30.08.2026 00:43:22.856]    <24> [0007]   Error (1)    Failed to execute full transform task
[30.08.2026 00:43:22.856]    <24> [0007]   Error (1)    Agent: Failed to process method {Transform.CompileFIB}: NfsFileEx was already stopped. File: [Host:, Mount: [/volume1/veeam], Disk: [Delilah ArcFS01 Backup/Delilah ArcFS01 Backup_2026-08-29T232336.vib], Type: [nfs3 (1)]] (Veeam.Backup.Common.CCppComponentException)
[30.08.2026 00:43:22.856]    <24> [0007]   Error (1)       in c++: Failed to execute command Command: READ, Offset: 2523136, Data size: 659456, Chunk size: 131072
[30.08.2026 00:43:22.856]    <24> [0007]   Error (1)       in c++: Failed to read file: Offset: 2523136, Block size: 659456, File: Path: [Host:, Mount: [/volume1/veeam], Disk: [Delilah ArcFS01 Backup/Delilah ArcFS01 Backup_2026-08-29T232336.vib], Type: [nfs3 (1)]], Handle: [01000702080061030000000007fffd5f65840fb20000000000000000150061038a2f7c0b0400610379207c0b], Read chunk size: 131072, Write chunk size: 131072, Read only: true

Because it continuously fails during the synthetic full, it eventually causes the snapshot to be lost when retries fail. The team will change this logic in a future update.

Action Items for the NFS Issue:
To help prevent these snapshot loss failures, could you please provide the logs from the repository NFS (192.168.20.91)?

1. Export the logs from the Veeam server and select the repository host.
2. Provide the results of running this command directly on the Repository host:

journalctl --since "30 days ago" > journal_repo.log

Temporary Workaround:
If you can, please temporarily switch to active fulls instead of synthetic fulls to help stabilize the job.

Please let me know if you have any questions, and if you are able to raise that ticket with Vates.

They also just responded back with this statment...

Regarding the second part of the last email with the noticed Synthetic full issue, I actually would like you to also make this registry entry on the Veeam server and keep synthetic fulls enabled to see if it helps with that issue:

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Name: Nfs3CommandWaitTimeoutSec
Type: DWORD
Value (In Decimal): 86400

SDN controller documentation link - page not found...

XO from sources latest commit - 280c0

So i just tried to apply the xcp-ng host updates release today.. I had an issue unable to apply updates as a vm could not migrate...

The problem was i had Nested Virtualization enabled on the vm. This was enabled for testing and forgot to disabled. However the error was not clear.

I am noting this to come back to when my xcp-pulse is further along.

vm.migrate
{
  "vm": "fb72a8d7-a039-849f-b547-24fc56f056ba",
  "migrationNetwork": "172b1b75-18cf-eed1-0a8c-0aca5e16f4e9",
  "targetHost": "c1372ec6-3651-4481-808b-34293e53e144"
}
{
  "code": "VM_IS_IMMOBILE",
  "params": [
    "OpaqueRef:1571e2f7-c235-dc10-d766-8883ddd99fd0"
  ],
  "task": {
    "uuid": "2b031b83-6b30-4a26-29c7-a19bf963ceb0",
    "name_label": "Async.VM.pool_migrate",
    "name_description": "",
    "allowed_operations": [],
    "current_operations": {},
    "created": "20260908T20:23:39Z",
    "finished": "20260908T20:23:39Z",
    "status": "failure",
    "resident_on": "OpaqueRef:119546e4-e0fd-adc7-d42a-b17c4efe789d",
    "progress": 1,
    "type": "<none/>",
    "result": "",
    "error_info": [
      "VM_IS_IMMOBILE",
      "OpaqueRef:1571e2f7-c235-dc10-d766-8883ddd99fd0"
    ],
    "other_config": {},
    "subtask_of": "OpaqueRef:NULL",
    "subtasks": [],
    "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_vm_lifecycle.ml)(line 758))((process xapi)(filename ocaml/xapi/xapi_vm_helpers.ml)(line 1657))((process xapi)(filename fun.ml)(line 33))((process xapi)(filename fun.ml)(line 38))((process xapi)(filename ocaml/xapi/helpers.ml)(line 1825))((process xapi)(filename ocaml/xapi/xapi_vm_helpers.ml)(line 1656))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 2584))((process xapi)(filename ocaml/xapi/rbac.ml)(line 228))((process xapi)(filename ocaml/xapi/rbac.ml)(line 238))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 78)))"
  },
  "message": "VM_IS_IMMOBILE(OpaqueRef:1571e2f7-c235-dc10-d766-8883ddd99fd0)",
  "name": "XapiError",
  "stack": "XapiError: VM_IS_IMMOBILE(OpaqueRef:1571e2f7-c235-dc10-d766-8883ddd99fd0)
    at XapiError.wrap (file:///opt/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12)
    at default (file:///opt/xen-orchestra/packages/xen-api/_getTaskResult.mjs:13:29)
    at Xapi._addRecordToCache (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1329:24)
    at file:///opt/xen-orchestra/packages/xen-api/index.mjs:1363:14
    at Array.forEach (<anonymous>)
    at Xapi._processEvents (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1353:12)
    at Xapi._watchEvents (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1560:14)"
}