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.

Hi @Andrew,

Thanks for the report. I'm seeing the same on my end, so I'll pass this along to the developers.

Dan

@olivierlambert Correct, it switches to Enterprise and then locks up because there isn't a license attached. Switching to the Stable release channel resolves the issue so that it is again running a valid XOA Free.

FWIW, I've verified this bug on XOA Free when on the Latest release channel.

@Lhoust I checked but was unable to locate a new ticket from you. I recommend going to https://vates.tech/contact/ and submit your inquiry from there. Be sure to provide the support tunnel ID if possible.

Have you tried resetting the VM's power state?

xe vm-reset-powerstate uuid=<UUID_of_the_VM> --force

There was a change a while back with the way Node handles timeouts, which affected instances of XOA where both IPv4 and IPv6 were assigned.

Temporarily adding the following entry to /etc/hosts will likely resolve the issue --
185.78.159.93 xen-orchestra.com

Hi Dustin,

Yes... these types of actions are recorded in the Audit log (Settings > Audit) if you have access to this feature and have enabled it.

Dan

Is xo-server running? Check systemctl status xo-server

You can also check the recent logs with journalctl -u xo-server -f -n 50

@rustylh Great! Are you now able to move beyond the error you posted above?

@rustylh Did you follow the instructions to visit the page and a cept the self-signed certificates?