@pedro_udifar Please update to the latest code base and then let us know if you still encounter this issue.

@pedro_udifar What is your current commit for the XO VM? Can you share the full error log as an attachment?

@rvreugde I believe this is already being reviewed internally.

@acebmxer Do you have VMs that aren't configured for HA? Does it work if you temporarily disable HA?

@pkgw Thanks for the feedback. The good news is that there is already an effort under way rework and enhance the RPU process. Let me ping @Team-XAPI-Network and @Team-XO-Backend in case they want to request additional information from you.

It's possible that you hit this known issue.

If you haven't rebooted after patching, then that could be a contributing factor.

Have you tried restarting the toolstack?

To investigate further, you can review the host's log files https://docs.xcp-ng.org/troubleshooting/log-files/

IIUC, the Smart Reboot option found on the host's Advanced tab does what you are asking.

@skipthompson81 said:

this CONFLICT is not OK!

You will need to provide more details about this specific backup job. It's possible that the backup succeeded, but then the subsequent Health Check failed or timed out. Have you tried downloading and examining the full log from the failed backup?

I'm not positive, but this may be available RSN in xo-lite.

@Greg_E Looks to me like the timeouts are occurring during the Health Check phase of the backup job. Thus the backup was successfully transferred to the remote, but the subsequent restoration and startup of the VMs failed because the VMs didn't respond in time.

Are you performing the Health Check on every backup run?

@andrewperry This script hasn't been designed or tested to work on XCP-ng 8.2.1 because it reached EOL status last year. Installing Python3 on XCP-ng 8.2.1 should be fine, but we aren't able to guarantee the script's functionality on that platform.

Upgrading to XCP-ng 8.3 is your best option here so that you can benefit from product improvements, security updates, etc.

@BrantleyHobbs You may want to provide some additional details on your setup, ie:

• Version of XCP-ng
• Are the host's fully patched?
• Current XO version or commit
• etc

Have you checked /var/crash subdirectory on the crashed host to see if kernel crash logs were captured? https://docs.xcp-ng.org/troubleshooting/log-files/

@limezest said:

ISOs in my NFS ISO SR

The simplest way to correct those is to forget the VDI and then rescan the SR.

Note: The ISO names will be lost if they were uploaded via XOA, which causes them to be renamed to .IMG files.

Nice. I believe that I read elsewhere that our dev team was working on something similar.

FYI, you have a typo (performace.sh vs performance.sh)

@IgorGlock Are you able to open the support tunnel for us to investigate? You can either post the tunnel ID here or open a support ticket.

@IgorGlock Thanks for the report. Can you elaborate on the exact steps required to reproduce this? Also, are you running XOA or XO from sources? Which version or commit?

@acebmxer The documentations says to use Node LTS, which is currently Node v24. There may have been past issues with running on Node v24. However, AFAIK XO should build and operate fine on Node v24 now.

Node v24 should work fine. The reason for your failure is here --

error eslint-visitor-keys@5.0.1: The engine "node" is incompatible with this module. Expected version "^20.19.0 || ^22.13.0 || >=24". Got "23.11.0"

Either upgrade Node to v24 or downgrade it to v22.