acebmxer

acebmxer

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

acebmxer

@rzr said:

We pushed the tested packages along a xen security update to the xcp-ng-updates repository, check blog post for summary and related advisories:
https://xcp-ng.org/blog/2026/07/28/july-2026-updates-1-for-xcp-ng-8-3-lts/

Just updated my homelab hosts.

[10:45 xcp-ng-disjqdnc ~]# yum clean metadata
Loaded plugins: fastestmirror
Cleaning repos: xcp-ng-base xcp-ng-updates
6 metadata files removed
4 sqlite files removed
0 metadata files removed
[10:45 xcp-ng-disjqdnc ~]# yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-base: mirrors.xcp-ng.org
Excluding mirror: updates.xcp-ng.org
 * xcp-ng-updates: mirrors.xcp-ng.org
xcp-ng-base/signature                                                                                                |  473 B  00:00:00     
xcp-ng-base/signature                                                                                                | 3.0 kB  00:00:00 !!! 
xcp-ng-updates/signature                                                                                             |  473 B  00:00:00     
xcp-ng-updates/signature                                                                                             | 3.0 kB  00:00:00 !!! 
(1/2): xcp-ng-base/primary_db                                                                                        | 3.9 MB  00:00:00     
(2/2): xcp-ng-updates/primary_db                                                                                     | 1.6 MB  00:00:01     
Resolving Dependencies
--> Running transaction check
---> Package xen-dom0-libs.x86_64 0:4.17.6-9.3.xcpng8.3 will be updated
---> Package xen-dom0-libs.x86_64 0:4.17.6-9.3.1.xcpng8.3 will be an update
---> Package xen-dom0-tools.x86_64 0:4.17.6-9.3.xcpng8.3 will be updated
---> Package xen-dom0-tools.x86_64 0:4.17.6-9.3.1.xcpng8.3 will be an update
---> Package xen-hypervisor.x86_64 0:4.17.6-9.3.xcpng8.3 will be updated
---> Package xen-hypervisor.x86_64 0:4.17.6-9.3.1.xcpng8.3 will be an update
---> Package xen-libs.x86_64 0:4.17.6-9.3.xcpng8.3 will be updated
---> Package xen-libs.x86_64 0:4.17.6-9.3.1.xcpng8.3 will be an update
---> Package xen-tools.x86_64 0:4.17.6-9.3.xcpng8.3 will be updated
---> Package xen-tools.x86_64 0:4.17.6-9.3.1.xcpng8.3 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================================
 Package                          Arch                     Version                                   Repository                        Size
============================================================================================================================================
Updating:
 xen-dom0-libs                    x86_64                   4.17.6-9.3.1.xcpng8.3                     xcp-ng-updates                   704 k
 xen-dom0-tools                   x86_64                   4.17.6-9.3.1.xcpng8.3                     xcp-ng-updates                   2.0 M
 xen-hypervisor                   x86_64                   4.17.6-9.3.1.xcpng8.3                     xcp-ng-updates                   2.4 M
 xen-libs                         x86_64                   4.17.6-9.3.1.xcpng8.3                     xcp-ng-updates                    66 k
 xen-tools                        x86_64                   4.17.6-9.3.1.xcpng8.3                     xcp-ng-updates                    47 k

Transaction Summary
============================================================================================================================================
Upgrade  5 Packages

Total download size: 5.2 M
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
(1/5): xen-dom0-tools-4.17.6-9.3.1.xcpng8.3.x86_64.rpm                                                               | 2.0 MB  00:00:00     
(2/5): xen-dom0-libs-4.17.6-9.3.1.xcpng8.3.x86_64.rpm                                                                | 704 kB  00:00:00     
(3/5): xen-libs-4.17.6-9.3.1.xcpng8.3.x86_64.rpm                                                                     |  66 kB  00:00:00     
(4/5): xen-hypervisor-4.17.6-9.3.1.xcpng8.3.x86_64.rpm                                                               | 2.4 MB  00:00:00     
(5/5): xen-tools-4.17.6-9.3.1.xcpng8.3.x86_64.rpm                                                                    |  47 kB  00:00:00     
--------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                       2.9 MB/s | 5.2 MB  00:00:01     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : xen-libs-4.17.6-9.3.1.xcpng8.3.x86_64                                                                                   1/10 
  Updating   : xen-hypervisor-4.17.6-9.3.1.xcpng8.3.x86_64                                                                             2/10 
  Updating   : xen-dom0-libs-4.17.6-9.3.1.xcpng8.3.x86_64                                                                              3/10 
  Updating   : xen-tools-4.17.6-9.3.1.xcpng8.3.x86_64                                                                                  4/10 
  Updating   : xen-dom0-tools-4.17.6-9.3.1.xcpng8.3.x86_64                                                                             5/10 
  Cleanup    : xen-dom0-tools-4.17.6-9.3.xcpng8.3.x86_64                                                                               6/10 
  Cleanup    : xen-tools-4.17.6-9.3.xcpng8.3.x86_64                                                                                    7/10 
  Cleanup    : xen-dom0-libs-4.17.6-9.3.xcpng8.3.x86_64                                                                                8/10 
  Cleanup    : xen-hypervisor-4.17.6-9.3.xcpng8.3.x86_64                                                                               9/10 
  Cleanup    : xen-libs-4.17.6-9.3.xcpng8.3.x86_64                                                                                    10/10 
  Verifying  : xen-dom0-tools-4.17.6-9.3.1.xcpng8.3.x86_64                                                                             1/10 
  Verifying  : xen-dom0-libs-4.17.6-9.3.1.xcpng8.3.x86_64                                                                              2/10 
  Verifying  : xen-hypervisor-4.17.6-9.3.1.xcpng8.3.x86_64                                                                             3/10 
  Verifying  : xen-libs-4.17.6-9.3.1.xcpng8.3.x86_64                                                                                   4/10 
  Verifying  : xen-tools-4.17.6-9.3.1.xcpng8.3.x86_64                                                                                  5/10 
  Verifying  : xen-libs-4.17.6-9.3.xcpng8.3.x86_64                                                                                     6/10 
  Verifying  : xen-dom0-tools-4.17.6-9.3.xcpng8.3.x86_64                                                                               7/10 
  Verifying  : xen-hypervisor-4.17.6-9.3.xcpng8.3.x86_64                                                                               8/10 
  Verifying  : xen-tools-4.17.6-9.3.xcpng8.3.x86_64                                                                                    9/10 
  Verifying  : xen-dom0-libs-4.17.6-9.3.xcpng8.3.x86_64                                                                               10/10 

Updated:
  xen-dom0-libs.x86_64 0:4.17.6-9.3.1.xcpng8.3 xen-dom0-tools.x86_64 0:4.17.6-9.3.1.xcpng8.3 xen-hypervisor.x86_64 0:4.17.6-9.3.1.xcpng8.3
  xen-libs.x86_64 0:4.17.6-9.3.1.xcpng8.3      xen-tools.x86_64 0:4.17.6-9.3.1.xcpng8.3

acebmxer

@rzr

Updates applied...

Updated:
  forkexecd.x86_64 0:26.1.11-1.2.xcpng8.3                         kexec-tools.x86_64 1:2.0.15-21.1.xcpng8.3                           
  message-switch.x86_64 0:26.1.11-1.2.xcpng8.3                    qcow-stream-tool.x86_64 0:26.1.11-1.2.xcpng8.3                      
  rrdd-plugins.x86_64 0:26.1.11-1.2.xcpng8.3                      sm-cli.x86_64 0:26.1.11-1.2.xcpng8.3                                
  squeezed.x86_64 0:26.1.11-1.2.xcpng8.3                          varstored-guard.x86_64 0:26.1.11-1.2.xcpng8.3                       
  vhd-tool.x86_64 0:26.1.11-1.2.xcpng8.3                          wsproxy.x86_64 0:26.1.11-1.2.xcpng8.3                               
  xapi-core.x86_64 0:26.1.11-1.2.xcpng8.3                         xapi-nbd.x86_64 0:26.1.11-1.2.xcpng8.3                              
  xapi-rrd2csv.x86_64 0:26.1.11-1.2.xcpng8.3                      xapi-storage-script.x86_64 0:26.1.11-1.2.xcpng8.3                   
  xapi-tests.x86_64 0:26.1.11-1.2.xcpng8.3                        xapi-xe.x86_64 0:26.1.11-1.2.xcpng8.3                               
  xcp-networkd.x86_64 0:26.1.11-1.2.xcpng8.3                      xcp-rrdd.x86_64 0:26.1.11-1.2.xcpng8.3                              
  xenopsd.x86_64 0:26.1.11-1.2.xcpng8.3                           xenopsd-cli.x86_64 0:26.1.11-1.2.xcpng8.3                           
  xenopsd-xc.x86_64 0:26.1.11-1.2.xcpng8.3                       

Complete!

Will continue to test.

acebmxer

@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.

acebmxer

@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.

Screenshot 2026-04-23 143142.png

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

Screenshot 2026-04-23 155432.png

Screenshot 2026-04-23 155727.png

acebmxer

@olivierlambert Created new topic.

acebmxer

@rzr

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

acebmxer

@julienXOvates

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

Confirmed is working in XOA in 6.4.1

Screenshot 2026-05-05 083337.png

acebmxer

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.

Log into the XO web UI with the dedicated account

Generate a token:

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

Copy the id field from the response

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

acebmxer

Confirm commit 1a7b5 backups completed successfully.

acebmxer

I have also opened a support ticket with Veeam. Well trying to... Issue with my account preventing me to and working to fix that issue.

Veeam forum did make this statment about CBT and snapshots -

There is one known snapshot issue that I'm guessing could possibly have this side-effect (noted in the release notes BTW). We take standard Xen snapshots for CBT but then immediately rename them with our own naming convention. We've noticed that sometimes this rename operation returns success status even if it fails. In this case I can see how this might throw this sort of error but again best to confirm w/support

Veeam support ticket - 08188639

acebmxer

@JB @gregbinsd @olivierlambert

Yes restarting the tool stack works for me. I currently do not have any host offline at least not intentionally. If there is a network glitch that i am not aware of that might cause the issue if that is the actual cause.

As @olivierlambert stated maybe we were having issues all along and they just changed something that is making the issue visible now. The support tunnel should still be open on my environment if you or the team want to look at logs.

acebmxer

@pierrebrunet

No worries,
Mine seems to be intermittent and restarting that pools tool stack resolves the issue for now.

acebmxer

@pierrebrunet

I use nfs for my remotes and still get the error occasionally.

Edit - Note i am only seeing this error in my work production environment. I am not seeing this issue in my home lab. Both use NFS for remote storage and vm storage.

acebmxer

So I ended up going with the Windows B&R as i could net setup the windows mount server when setting up the repo for the backups. It would setup the linux one but not the windows one. This was with using the veeam console from a windows client. So i ended up with the Windows one.

Now after a few backups i am see this warning / error....

8/5/2026 5:34:50 PM Warning : Failed to use CBT: [Task e75c4247-2ee1-7b51-088c-b970ace60f3d (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]

First i thought it was because i maped the new job to older backups from Beta v1. So i purged all old backups and started fresh. The full backups were successful. Now on first delta 4 out of 7 vms have that warrning.

This a Veeam issue or xcp-ng?

acebmxer

@msupport said:

The CBT metadata VDIs remain as snapshots, but their VHD parent references point to nothing. The tapdisk crashes, the VM loses disk access, the filesystem becomes corrupt.

For VM-A (SQL Server), both disks (60GB + 80GB) have broken CBT snapshots. virtual-size=0, physical-utilisation=0.

For VM-B (File Server), the 80GB disk has a broken CBT snapshot. Interestingly: virtual-size=85899345920 (80GB, same as the base disk) and physical-utilisation=8388608 (8MB). This is different behavior from VM-A — possibly a different code path in the CBT lifecycle.

In my testing i did see similar issue

Edit - updated with actual error message from what I am getting. The first full backup were all successful. This first delta backup have 4 vms with this error. The first time I saw similar was only 2 vms.

8/5/2026 5:34:50 PM Warning : Failed to use CBT: [Task e75c4247-2ee1-7b51-088c-b970ace60f3d (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]

For me i took it as because i original had backups from veeam 12.x the first xcp-ng beta. Pointed new backups from 13.1 to older backups. I then purged all older backups and started with a fresh backup chain.

I ended up reverting to the windows base as i was not able to get the windows mount server setup. This was setting up from a windows client using the console to setup the repo.

acebmxer

@olivierlambert

Mine has not done it since last post but i have opened a support ticket along with tunnel being opened - Ticket#7762089

acebmxer

If i recall from my migration I belive thats all there is to it. I know the docs mention about doing a test migration but mine just migrated and it just worked as you stated after making the needed adjustments.

Let other chime in but i think you are good to go. And you could delete the snapshot from the vm.

acebmxer

@msupport said:

@acebmxer You need two Disk with 300GB

If this is a reply to my initial post. I have already got it installed. Where do you see this 300GB requirement?

https://helpcenter.veeam.com/docs/vbr/em/system_requirements.html?ver=13

Disk Selection Logic: When selecting a disk for system and adjacent functions, Veeam Software Appliance automatically chooses an SSD over an HDD, and selects the smaller disk of the two available. The sizing recommendations for Disk 1 below remain valid for the system disk.

Disk 1: 240 GB1 minimum. This disk hosts Veeam JeOS, Enterprise Manager Veeam Backup & Replication software, configuration database and instant recovery cache.

Recommended sizing depends on the number of protected workloads. Sizing also accounts for configuration database growth as you add more workloads to protect:

480 GB1 SSD for small environments (up to a few hundred workloads).
960 GB1 SSD for medium-sized environments (up to a few thousand workloads).
Multi-TB1 SSD for large environments. Larger capacity increases the disk space available to instant recovery cache, allowing for running more machines for longer time.
Note: After Veeam Software Appliance deployment, adding new storage devices or resizing existing ones is not supported. Plan your disk capacity carefully before you start the deployment.

Disk 2: 240 GB1 minimum. This disk hosts guest file system catalogs and backups, therefore recommended sizing depends on your backup storage needs. Any additional disks found in the system during Veeam Software Appliance deployment will be automatically joined with Disk 2 into the single Logical Volume Manager (LVM) spanned volume.

This is only backing a few vms around 10 vms, and actual location is to nfs storage.

acebmxer

Just got a failure today but with a different pool.

    "message": "backup task failed with undefined error",
    "name": "Error",
    "stack": "Error: backup task failed with undefined error\n    at forwardResult (file:///usr/local/lib/node_modules/xo-server/src/_handleBackupLog.mjs:37:25)\n    at handleBackupLog (file:///usr/local/lib/node_modules/xo-server/src/_handleBackupLog.mjs:68:12)\n    at onTaskUpdate (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/metadata-backups.mjs:117:13)\n    at onTaskUpdate (file:///usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/mixins/Tasks.mjs:205:23)\n    at onLogFct (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/combineEvents.js:61:5)\n    at metadataBackup._executor (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/metadata-backups.mjs:122:11)\n    at Jobs.runJob (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/jobs/index.mjs:297:7)\n    at file:///usr/local/lib/node_modules/xo-server/src/api/schedule.mjs:84:9\n    at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:204:22)\n    at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:188:20)\n    at Xo.runSequence (file:///usr/local/lib/node_modules/xo-server/src/api/schedule.mjs:73:3)\n    at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:204:22)\n    at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:188:20)\n    at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:475:18)"
  }
}

acebmxer

@acebmxer

Available Functions

Interactive Menu

Quick Start

Configuration

Default Credentials

Supported Operating Systems

Running Task Detection (Update Safety)

Authentication

Recommended: Dedicated XO Account

Using an Auth Token (Recommended)

Using Credentials

Environment Variables

Troubleshooting

Build fails with OOM / out-of-memory error

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

git reports "dubious ownership" and exits

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

License

Credits

`git` reports "dubious ownership" and exits