@flakpyro said in backup mail report says INTERRUPTED but it's not ?: @olivierlambert Using the prebuilt XOA appliance which reports: [08:39 23] xoa@xoa:~$ node --version v20.18.3 @majorp93 @pilow Can you please capture some heap snapshots from during backup runs of XOA via NodeJS? Then compare them to each other, they need to be in the following order:- Snapshot before backup Snapshot following first backup Snapshot following second backup Snapshot following third backup Snapshot following subsequent backups to get to Node.js OOM (or as close as you’re willing to risk) These will require that XOA (or XOCE) is started with Node.js heap snapshots enabled. Then open in a Chromium based browser the following url:- chrome://inspect The above URL will require using the browser’s DevTools features! Another option is to integrate and enable use of Clinic.js (clinic heapprofiler), or configure node to use node-heapdump when it reaches a threshold amount. Once your got those heap dumps your looking for the following:- Object types that grow massively between the snapshots. Large arrays or maps of backup-related objects (VMs, snapshots, jobs, tasks, etc.). Retained objects whose “retainers” point to long-lived structures (global, caches, singletons). These will likely help to pin down what and where in the backup code, the memory leak is located. Once have these a heap snapshot diff showing which object type (or types) growing by a stated size per backup will finally help the Vates developers fix this issue. @florent I left the above for the original reporters of the memory leak issue, and/or yourselves.

@MichaelCropper Truenas on bare metal just as storage, XCP-NG is also bare metal on 3 hosts to make a pool. That's the minimum if you want to enable High Availability, it also works really well as a "normal" pool which is what I have. Rolling Pool functions are great, click the button and the system moves the VMS off of the host that need updates, reboots, moves VMs off of the next host, repeat. Only works with Shared storage.

I appreciate the comments and they are all welcome. Do keep note that I did say this is not Production ready and use at your own risk. If you see anything that is wrong please provide suggest feedback to correct said issue. I just started running my home lab from this version yesterday. I imported my config from previous XO. Today i saw 4 new commits and the update function updated to the latest commit. Backups have run with no issue. As I can only test in my home lab I can only speak of my own experiences.

@Danp alright, thanks. I'll give that a try.

If they can get Doom to run on a female healthcare product, I think we should work to get XCP-ng to work on said same product.... https://www.youtube.com/watch?v=V1gcoyo5Ssk haha...

@afmart_dei I'd be surprised that you can't add this host to the pool because it has a different number of PIFs... more likely than not the version mismatch is what is getting you hung up here. Is there anyway to update everything to the same level, once that is done then you should be able to add this host to the pool. As for Windows XP, CentOS 4 (CentOS 4 was EoL'd in 2012.... only 14 years ago) so that's likely gonna be a hard no. XP was in 2014.. likely the same boat. The issue likely being that no one wants to program on old ass OS's to support something that the original dev no longer supports.

@tmnguyen You can open a support ticket and request that we reactivate your XOSTOR trial licenses to match your existing XOA trial.

said in Commit 109e376 Implications: we are currently drafting a procedure to make it the easiest possible. FYI: https://github.com/vatesfr/xen-orchestra/pull/9525 More details to come in upcoming weekS thomas-dkmt opened this pull request in vatesfr/xen-orchestra open docs(sdn_controller.md): document openssl 3 + sdn upgrade path #9525