Finally just finished our migration from VMware to XCP-NG.

VMs - 34 mix windows server and ubuntu linux.
Pools - 3
Host - 6
Dell R660 - 2
Dell R640 - 4

@rzr Installed latest update and no issues to report. I dont hvae any 2tb+ drives in my vms. converting from vhd to qcow2 and backups all working.

@rzr

installed updates will report back.

Update - I had migrated vms back over to vhd prior to update release. I have migrated 2 vms back over to qcow2 and the initial backup ran successfull. Ran a second delta backup and that as well was successful with out issues. Backups happen very quickly now. But it appears the % and progress bar are working.

When CBT is enabled on the vm vdi. They show up as needing to be coalesced. VMs without CBT enabled the vdis are coalesced.

Will continue to monitor.

Once the coalesence hits 2 for the vm. The vm is skipped form future backups until cleared. (shutting down the vm will allow the coalescence to happen.
2026-04-23T19_52_34.694Z - backup NG.txt

@olivierlambert Created new topic.

@rzr

Updated my to AMD Ryzen host in my home lab. No issues with update will monitor and report back any issues.

@julienXOvates

Ok that was in xo from sources and yes issue is fixed...

Confirmed is working in XOA in 6.4.1

While this project is more for myself it is open to others to use. Please use at your own risk. As always review the script before using in a production environment. Please leave any feedback or suggestions. https://github.com/acebmxer/install_xen_orchestra/
https://forums.pozzatech.com - You can read more about this project and other things over in my personal forums.

Automated installation and management of Xen Orchestra from source.

Update 5/15/26 - This update only applies to anyone using older version of script. See note. Also added option to Adjust Xen Orchestra Memory Allocation. It will look at the system memory and suggest setting for XO based off the official documentation.

⚠️ Upgrading from an earlier version of this script? Read this first.
This version bumps the config schema to v2 (adds PUBLIC_URL and ENCRYPT_REDIS_CREDENTIALS) and corrects two config.toml generation bugs. Your xo-config.cfg is migrated automatically and non-destructively, but the corrected /etc/xo-server/config.toml is only written by --reconfigure.

Run --reconfigure once before resuming normal updates:

./install-xen-orchestra.sh --reconfigure
This regenerates config.toml with the fixes (your old file is backed up first; data in /var/lib/xo-server is untouched). It is strongly recommended if you set both REDIRECT_TO_HTTPS=true and REVERSE_PROXY_TRUST — that combination previously produced a duplicate [http] section and silently dropped one of the settings.

Afterwards, run --update as normal for routine XO updates — --update does not need to be preceded by --reconfigure again.

Available Functions

Function	CLI Flag	Description
Install	--install	Fresh install of Xen Orchestra
Update	--update	Update existing installation (with backup)
Restore	--restore	Restore from a previous backup
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
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

Interactive Menu

Running the script with no arguments opens a two-column menu with keyboard navigation:

  ╔══════════════════════════════════════════════════════════════════════════════════╗
  ║              Install Xen Orchestra from Sources Setup and Update                 ║
  ╚══════════════════════════════════════════════════════════════════════════════════╝

                        Current Script Commit : 693f4 (Branch: main)
                        Master Script Commit  : 693f4 (Branch: main)
                        Current XO Commit     : a1b2c (Branch: master)
                        Master XO Commit      : d4e5f (Branch: master)
                        Current Node          : v24.15.0

  ──────────────────────────────────────────────────────────────────────────────────

  ▸ [✓] Install Xen Orchestra                   [ ] Reconfigure Xen Orchestra
    [ ] Update Xen Orchestra                    [ ] Rebuild Xen Orchestra
    [ ] Rename Sample-xo-config.cfg             [ ] Edit xo-config.cfg
    [ ] Install XO Proxy                        [ ]  Restore Backup
                         [ ] Adjust Xen Orchestra Memory Allocation

  ──────────────────────────────────────────────────────────────────────────────────

  Selected: 1

  ↑↓←→ Navigate   SPACE Select/Deselect   ENTER Confirm   Q Quit

Select one or more items with SPACE, then press ENTER to run them.

Quick Start

git clone https://github.com/acebmxer/install_xen_orchestra.git
cd install_xen_orchestra
cp sample-xo-config.cfg xo-config.cfg
nano xo-config.cfg   # edit to your liking
./install-xen-orchestra.sh

Do NOT run with sudo. Run as a normal user with sudo privileges — the script handles sudo internally.

If xo-config.cfg doesn't exist, it will be created automatically from the sample.

Configuration

All settings live in xo-config.cfg. See sample-xo-config.cfg for full documentation of every option.

Key settings:

Option	Default	Description
HTTP_PORT	80	HTTP port
HTTPS_PORT	443	HTTPS port
INSTALL_DIR	/opt/xen-orchestra	Installation directory
GIT_BRANCH	master	Git branch or tag
NODE_VERSION	24.15.0	Node.js version
SERVICE_USER	xo-service	Service user (set to root for VMware V2V import)
BACKUP_KEEP	5	Number of backups to retain
BIND_ADDRESS	0.0.0.0	Bind address
REVERSE_PROXY_TRUST	false	Trust X-Forwarded headers from proxy IP

Note on BACKUP_KEEP rotation: The retention policy only applies to backups created by the current version of the script. Backups made by older script versions may use a different naming convention and will not be counted or pruned by the rotation logic. If you are upgrading from an older version, manually review your backup directory (BACKUP_DIR in config, default /var/lib/xo-backups) and remove any legacy-named archives you no longer need.

Default Credentials

After installation, access the web interface at https://your-server-ip.

• Username: admin@admin.net
• Password: admin

Change the default password immediately after first login.

Supported Operating Systems

• Debian 10/11/12/13
• Ubuntu (all supported versions)
• RHEL / CentOS / AlmaLinux / Rocky
• Fedora

Running Task Detection (Update Safety)

Before applying an update, the script queries the Xen Orchestra REST API for active tasks (e.g. running backups, VM exports). If any are found, the update is aborted to prevent data loss or corruption.

Authentication

Only admin-level XO accounts can access the REST API. Authentication is resolved in priority order:

Priority	Method	Source
1	Auth token	XO_TASK_CHECK_TOKEN in xo-config.cfg
2	Credentials	XO_TASK_CHECK_USER / XO_TASK_CHECK_PASS in xo-config.cfg
3	Interactive	Prompted at runtime (press Enter to skip)

Recommended: Dedicated XO Account

It is recommended to create a dedicated XO web UI account solely for the task check (e.g. task-checker@local.net). This account:

• Must have Admin privileges (required by the REST API)
• Exists only within the XO web interface — no shell access, SSH keys, or OS-level permissions are needed
• Provides a clear audit trail separate from personal accounts
• Prevents shared credentials from being used for unrelated actions

You are free to use any admin account you choose, but a dedicated account is the safest approach.

Using an Auth Token (Recommended)

Tokens are more secure than storing a password — they can be revoked independently and expire after 30 days by default.

1. Log into the XO web UI with the dedicated account
2. Generate a token:

   curl -X POST -u 'task-checker@local.net:yourpassword' \
     https://localhost/rest/v0/users/me/authentication_tokens -k
   

3. Copy the id field from the response
4. Add to xo-config.cfg:

   XO_TASK_CHECK_TOKEN=UlTBEnFeL12XocK-7Qx-DKvOYbPn0eG7Z2oMvOniNjg
   

Using Credentials

Alternatively, store the account credentials directly:

XO_TASK_CHECK_USER=task-checker@local.net
XO_TASK_CHECK_PASS=changeme

If neither token nor credentials are configured, the script will prompt interactively during each update.

Environment Variables

Variable	Description
XO_DEBUG=1	Enable debug mode (set -x)
XO_NO_SELF_UPDATE=1	Skip automatic script self-update

Troubleshooting

Check service logs:

sudo journalctl -u xo-server -n 50

If the build is broken, rebuild (takes a backup first):

./install-xen-orchestra.sh --rebuild

Build fails with OOM / out-of-memory error

The Yarn build is memory-intensive. On hosts with less than 2 GB RAM the Node.js process can be killed by the kernel OOM killer mid-build, leaving an incomplete install.

Add or increase swap to give the build room:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Re-run the install or --rebuild after the swap is active. To make it permanent across reboots, add /swapfile none swap sw 0 0 to /etc/fstab.

NodeSource GPG key failure (air-gapped / offline hosts)

On hosts without internet access (or with strict egress firewall rules) the NodeSource repository setup script fails because it cannot reach keyserver.ubuntu.com or deb.nodesource.com.

Option A — pre-download and import the key manually, then copy the .deb/.rpm packages to the host.

Option B — set NODE_VERSION to a specific patch version (e.g. 24.15.0) in xo-config.cfg. The script will then download a pre-built binary directly from nodejs.org instead of using the NodeSource package repository.

git reports "dubious ownership" and exits

Recent versions of Git refuse to operate on a repository owned by a different user than the one running the command. This can happen when sudo is used inconsistently or when the install directory was created by root but the script is run as a normal user.

Fix it by resetting ownership to match your SERVICE_USER:

sudo chown -R xo-service:xo-service /opt/xen-orchestra

Replace xo-service with the value of SERVICE_USER in xo-config.cfg. Re-running the script afterwards will resolve the rest.

RedHat / Rocky / AlmaLinux: SELinux denials or systemd capability errors

On SELinux-enforcing systems the xo-server service may fail to bind ports or access network resources. Check for AVC denials:

sudo ausearch -m avc -ts recent | grep xo-server

If denials are present, generate and apply a local policy module:

sudo ausearch -m avc -ts recent | audit2allow -M xo-server-local
sudo semodule -i xo-server-local.pp

Alternatively, set the service to permissive mode while investigating:

sudo semanage permissive -a xo_server_t

audit2allow and semanage are provided by the policycoreutils-python-utils package on RHEL/Rocky/Alma.

License

This project is licensed under the MIT License. Xen Orchestra itself is licensed under AGPL-3.0.

Credits

• Xen Orchestra by Vates
• Installation Documentation

Confirm commit 1a7b5 backups completed successfully.

@simonp

[info] Updating Xen Orchestra from 'cb85e44ae' to 'eed3d72f7'

First log is from automatic schedule before latest update.
2026-02-17T18_00_00.012Z - backup NG.txt

latest log after update. Backup completed successfully.
2026-02-17T18_22_52.199Z - backup NG.txt

Updated AMD Ryzen pool at home and update two Intel Dell r660 and r640 pools at work. No issues to report back.

I was going to suggest it might be a amd issue. I can try later on work host that are intel.

@TeddyAstie

This is on fresh install Debian 13 deployed from XO Hub - 6.12.38+deb13-amd64. I do not see this behavior on Ubuntu.

after update 6.12.90+deb13.1-amd64
still happens.

@TeddyAstie

From Debian 13 cloud inti. Does on every reboot from fresh image.

added more vcpus.

@rzr

Installed updates on home lab. No issues to report initially other then nslookup still an issue.

[10:54 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   vates.com
Address: 104.21.52.238
Name:   vates.com
Address: 172.67.205.118

openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace
#0 0x7f163cd960e7 in ??
#1 0x7f163cd9603a in ??
#2 0x7f163d9a3780 in ??
#3 0x7f163c1aedf6 in ??
#4 0x7f163c1f5464 in ??
#5 0x7f163c1f5732 in ??
#6 0x7f163c1f4b8d in ??
#7 0x7f163a95fbd9 in ??
#8 0x7f163a95fc27 in ??
#9 0x7f163a94844c in ??
#10 0x405818 in ??
Aborted (core dumped)
[12:50 xcp-ng-haznrrtw ~]# 

@jcdick1

Have you tried to refresh PIFs on the host in question?

@pierrebrunet said:

@CGB Hi, are you running XO from source with root or another user?
If it is another user, it may be not accessible from it

That is what i was able to determine what is going on with my script. - https://xcp-ng.org/forum/post/105965

when using root user button works just fine. If using non-root user the button will never work as it assumes root will use it. I am not sure how other scripts handle this issue.

After building new xo with root and more testing, I have come to this conclusion...

Both things are true, and they're in tension
The official docs prefer non-root for the long-running service — that's a least-privilege hardening recommendation for the daemon. Normal XO (UI, backups, hosts, VMs, NFS/CIFS remotes) works fine non-root.
But several XO features assume root anyway. The ESXi/VMware import "install from source" buttons are hard-coded to refuse unless id -u == 0. You already hit this same pattern once before — the credential-encryption/XenStore work (commit 5e8b7fd) existed precisely because non-root broke that too.
So "everything fails non-root" isn't quite it — what fails is the specific subset of features XO wrote assuming it runs as root. Each one needs a separate workaround. The import button is one that cannot be worked around for a non-root process: it's a uid check on the running daemon, full stop.

The honest trade-off
You can pick at most two of these three:

Service runs non-root (docs' preference)
In-app "install nbd from source" button works
Script doesn't pre-install packages
The button (#2) requires the daemon to be uid 0. So:

Want the button to work → run that box as SERVICE_USER=root. Simplest, everything XO ships just works, zero manual steps. You give up the non-root hardening.
Want to stay non-root → the button is permanently dead; the only way to get import working is the binaries being placed by root once (script or by hand). The binaries run fine as non-root — only their installation needs root.
My recommendation
Use SERVICE_USER=root on this box. XO's own codebase keeps assuming root (import, and you already saw it with encryption/XenStore), so non-root is a recurring fight against upstream for marginal hardening. Root is fully supported, it's what the official XO appliance ships, and it makes the buttons you want work with no manual package steps. Keep non-root only if hardening that box is a hard requirement and you're fine never using the in-app import installer.

While looking into the following issue - https://xcp-ng.org/forum/topic/11976/trying-to-enable-v2v-and-difficulty-adding-nbdinfo-on-xo-6/10

I found a few issues with my install script... Looking for recommendations on the fix approach.

I am noticing that are some confusion or inconsistencies with the documentation. Areas it suggest to use root and/or a non root account. Part of these issues would not be if the account used was root or with root access.

The two failures
Reason 1 — privileges (SERVICE_USER=xo-service, non-root):
XO's button runs apt-get install ..., make install, and ldconfig with no sudo (confirmed in esxi.mjs source). As xo-service, those commands are permission-denied: it can't apt-install, can't write to /usr/local/..., can't run ldconfig. XO's own dependency checker even says V2V requires root (UID 0) — which is why your sample-xo-config.cfg:56 already warns "V2V import requires root."

So yes — your instinct is correct. With SERVICE_USER=xo-service, the button cannot succeed no matter what.

But Reason 2 — build tools absent:
Even if you set SERVICE_USER=root and click the button, it will then try apt-get install -y git dh-autoreconf pkg-config make libxml2-dev ocaml libc-bin and compile from GitLab. That will work if the box has internet and apt is healthy — but it's a multi-minute source compile pulling ~hundreds of MB (ocaml!) every time, done live inside the web request. Pre-staging those packages via the installer makes the button fast and reliable instead of a long live compile.

So, is the fix "just set SERVICE_USER=root"?
To make the button function: yes, that is the necessary fix. Pre-installing build deps is an optional reliability/speed improvement on top.

Given your answers, here's my refined proposal — minimal, docs-aligned:

Proposed changes

1. Add INSTALL_V2V_DEPS=false opt-in to sample-xo-config.cfg. When true, the installer pre-stages XO's exact build-dep list (git dh-autoreconf pkg-config make libxml2-dev ocaml libc-bin) on apt systems only, so the button compiles quickly instead of installing them live. Default false → no ocaml bloat on normal installs.

2. Root guard (your "Warn only" preference): When INSTALL_V2V_DEPS=true and SERVICE_USER is non-root, print a prominent warning:

"VMware V2V import requires xo-server to run as root (per XO docs). The in-XO 'install nbdinfo' button runs apt-get/make install without sudo and will fail as user '$SERVICE_USER'. Set SERVICE_USER=root to use V2V import."
…and continue (don't abort).

3. RHEL/dnf: if INSTALL_V2V_DEPS=true on a non-apt system, log "VMware V2V import is only officially supported on Debian 12/13 per XO docs — skipping V2V dependency setup." and do nothing.

4. Keep the existing /usr/local/lib/vddk dir creation (it's correct — XO untars VDDK there), and don't touch APT contrib/multiverse or pre-compile nbdkit (XO compiles from source itself; distro packages are never used by the button).

5. Docs: README row for INSTALL_V2V_DEPS + a sharpened note in sample-config that V2V needs SERVICE_USER=root, linking the official guide.

This stays strictly within what XO's own code does, scopes the heavy deps behind opt-in, and surfaces the real root-user requirement you correctly identified.

Shall I implement this? If yes, I'll make the edits and run shellcheck/bats afterward to verify nothing breaks. (I have not edited anything yet.)

Prior to looking into this issue. I was trying to work on switching from standard user to root but that broke alot of things and will need rework. Dont belive it would be an issue if root was used to initially deploy xo.

@CGB
Are you using XOA or XO from sources? If from sources, who's script did you use to deploy? Also if from source what commit are you on?

Applied patches at work. 3 pools updated with zero issues.