@Danp I would normally do this and report back however i am running a custom patch from @florent at the moment that he deployed to fix the "Fetch Failed" backup proxy issue. Once 6.8.2 has been released which that patch i should be able to switch between versions and test this!

@dkidd255 @jamesg I didn't forgot about it, but I still don't have access to relevant hardware (for reasons outside of my control). In the meantime, if that happens to be related, can you try the patch that allows disabling hvm-pirq ?

To sum up... It appears the patch has worked for me but has shed some light on miss configuration with the network design at this remote location, that I will need to take a real closer look at. @florent thank you very much for your continue assistance with my issues.

If you are running XOA, not XO from sources, then we could take a look remotely using the support tunnel. Otherwise, make sure that you have patched and rebooted each pool member.

v0.4.1 and v0.4.2 are out. v0.4.1 — mostly credential encryption (ENCRYPT_REDIS_CREDENTIALS) The preflight check now catches a Xen guest that's missing xenstore-read / xenstore-write. Before, that guest passed the systemd-detect-virt check and then failed later at xo-server startup, because there was nowhere to store the XenStore half of the key. It now names the missing tools and the package that provides them. --backup now warns that it contains neither half of the encryption key, and points at the passphrase-protected XO config export as the actual recovery artifact. --uninstall warns before deleting this host's on-disk key half — doing so while leaving Redis in place turns the stored records into unreadable ciphertext. The docs (README, sample config, generated config.toml comments) now explain why the XAPI credential in Redis is stored reversibly instead of hashed: it's replayed on every connect and auto-reconnect, so it can't be a hash. They also spell out the recovery caveats — the key is split between XenStore and /var/lib/xo-server/data, and losing either half while encryption is on makes the records permanently undecryptable. Also flagged in the sample config: pointing REDIS_URI at an off-host Redis sends the pool credentials over the network in cleartext. v0.4.2 — docs and packaging only, no behaviour change: The README had grown past 700 lines, with the --deploy walkthrough alone taking up a third of it. The large reference sections moved out to docs/deployment.md, docs/configuration.md, docs/authentication.md and docs/troubleshooting.md; the README is back to ~330 lines with a table pointing at them. Nothing was removed. Expanded the badge row — release tag, last commit, open issues, unit-test count, number of distros the CI container matrix covers, and ShellCheck status. Where the project's got to I started this in February as a script to save myself doing the from-source install by hand every time I rebuilt my homelab. Seven months and twelve tagged releases later it's grown into something a fair bit bigger: --install does the from-source build on whatever distro you run it on — the Debian/Ubuntu, RHEL/Alma/Rocky/CentOS and Fedora families, eight distributions in all, each one smoke-tested in CI alongside 118 unit tests. --deploy (added in v0.3.0) starts a step earlier: point it at a XCP-ng / XenServer pool and it builds the VM, pulls a Debian cloud image straight onto the pool, seeds it with cloud-init and runs the install inside it. It's there for people who have a pool but no Linux VM to put XO on. --proxy deploys an XO Proxy VM the same way — that one came straight out of requests in this thread. Around that: a config file so nothing needs editing in the script itself, --update / --rebuild with a local build cache, --backup / --restore / --uninstall, non-root operation with encrypted Redis credentials, firewall handling, and a lot of --deploy security work in v0.4.0 — image checksums, pool host-key pinning, the deploy SSH key destroyed at the end of the run, a required admin password, passwordless sudo revoked once the install finishes. Since the v0.3.0 / v0.4.0 post a couple of weeks ago the repo has had 263 clones from 49 unique cloners. Thanks To everyone in this thread who's installed it, tested it and come back with feedback — genuinely, thank you. The proxy support, the credential-encryption questions that turned into proper docs, the config-file suggestions, the distro edge cases on systems I don't run myself: several of the releases above have something in them that started as a post here. Keep it coming. Repo: https://github.com/acebmxer/install_xen_orchestra Changelog: https://github.com/acebmxer/install_xen_orchestra/blob/main/CHANGELOG.md

New version: https://github.com/dicode-nl/xcp-ng-ceph-rbd/releases/tag/v20260903 This one includes native Ceph rbd SXM over SMAPIv3! GitHub updated with the latest commits and changes. As always, use with caution. I did run a lot of test scenario's but please do test yourself and let me know your findings!

My reported issue is gone with build 7a187 from sourcecode. Day before: tasks 0 id "0mtj9shwq-k2neggnx0sf" properties id "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeca" name "backup VM" type "VM" name_label "unifi-server" progress 0 start 1788303601322 status "success" warnings 0 message "can't compute delta OpaqueRef:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeee76 from OpaqueRef:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeee32, fall back to a full" tasks Day after: 1 id "0mtktio1u-lrexahnlve" properties id "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeca" name "backup VM" type "VM" name_label "unifi-server" progress 0 start 1788397201218 status "success" tasks 0

This was sent to me yesterday!! See our Engineering Team lead's response: We evaluated XCP-ng 8.3 some time ago, but its dom0 kernel was too old for our driver to work properly. Running SupremeRAID inside a DomU should be feasible and is similar to the approach we previously proposed for VMware. However, with XCP-ng 8.3, we did not find a practical native path to export the SupremeRAID VD back to dom0 and use it as an XCP-ng SR. Using iSCSI for this purpose would add significant protocol and networking overhead, which is not ideal for high-performance NVMe storage. I revisited XCP-ng 9.0 and the current Xen/XAPI development. A more promising approach is to run SupremeRAID in a dedicated AlmaLinux VM with the GPU and NVMe drives passed through, then use Xen's native xen-blkback interface to export the SupremeRAID block device back to dom0. Dom0 would see the exported VD as a normal Xen block device, which could then potentially be used to create a standard XCP-ng LVM SR. This approach is much more attractive than iSCSI or NVMe/TCP because the data path uses Xen's blkif shared-memory interface rather than a network protocol. xen-blkback itself is an established Xen mechanism, and Xen supports using a separate domain as a block backend. However, XCP-ng does not currently provide complete first-class lifecycle management for this configuration, so we still need to validate the exact behavior on XCP-ng 9.0, particularly persistent attachment, storage VM startup ordering, and recovery after a host or storage VM reboot. If they can help confirm that the GPU and NVMe drives can be passed through to the storage VM, SupremeRAID can run normally there, and the resulting VD can be exported through xen-blkback to dom0 and used as an XCP-ng SR, I think this could be a very solid architecture for SupremeRAID on XCP-ng. As for write durability, SupremeRAID always operates in write-through mode. An I/O is acknowledged only after all associated data, including parity, has been committed to the drives. Therefore, acknowledged writes do not depend on data or parity remaining only in volatile GPU or host memory Can you do the initial testing with SupremeRAID PRO within your environment? I will begin the initial testing and builds with 4 nodes: 1 & 2 are HP DL380 Gen10 - 2x Xeon Gold 6151 36 Cores 384GB RAM 4 3.84Tb PCI4.0 NVMe per node. Twinstore Testing - Run the Build environment on these 3 is a HP Dl360 Gen10 2x Xeon Gold 6151 36 Cores 512Gb RAM 4x1.92TB NVMe Drives SuperServer SYS-122H-TN- X14 2x Xeon 6740 96 cores, 512GB RAM, GRAID Card - 4x Pci5.0 7.68TB drives SupremeRAID. All the nodes have 2x100Gbps ports, 2x25Gbps ports. Arista Backed network.