Restart the toolstack on each server.

You should be able to delete the snapshots without causing any harm. A couple of things to keep in mind --

• If the snapshot is associated with an existing backup job, then the next run of that job will result in a full backup instead of a delta

• It may take some time for the snapshots to coalesce following deletion, so this could still affect your backups until they are completely removed

• If you want to delete the backups associated with the old job, then you can from the Backup > Health tab in XO

It is also possible to perform this activity from within XO as described here. There are some prerequisites for performing this action that you should review -- https://docs.xcp-ng.org/installation/requirements/#-pool-requirements

I would setup a Continuous Replication backup job to create a duplicate VM on the new storage repository. When you are ready to perform the cutover, shutdown the original VM, perform one final run of the CR job, and then start the new VM on the new pool.

Interesting read that mentions xcp-ng!

https://www.theregister.com/2022/09/30/citrix_xen/

Yes, it's technically possible, as long as the underlying hardware is compatible. For example, you can't put a server using AMD processors into a pool with Intel processors.

The server being moved into the existing pool will lose its local storage and all VMs stored there, so you will need to migrate those VMs to the main pool before the server is merged. Afterwards, you can move them back if desired.

@JoyceBabu They are now available at https://www.xenserver.com/downloads

@jr-m4 Yes, it seems that all dropdown lists are broken by a recent dependency update. XO team has been notified.

@BrianDLC The error ""EACCES: permission denied" should have pointed you to a permissions error to begin with.

Since we have no knowledge of how that script operates, it often makes more sense to refer you to their repo for help rather than us guessing at the reason for the issue.

@Ascar I suspect that Olivier means to register with the XO instance using this syntax --

xo-cli register [--allowUnauthorized] [--expiresIn <duration>] [--otp <otp>] <XO-Server URL> <username> [<password>]

You can run xo-cli without any parameters to get the full usage text.

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.