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.

@DustinB said in Migrating logs and history between XOA instances?:

Every action that has taken place on the pool by XO, is what we were wanting to keep. But if you replace XO, you lose the logs as they are retained on the original XO.

If you are using the Audit plug-in, there is a way to move these entries to a new XOA deployments.

I assume that you are referring to other logs, like the ones appearing on a VM's Logs tab, correct?

@olivierlambert said in Update XOA OS via apt update?:

unintended updates

I think Olivier meant "unattended".

The latest XOA release is based on Debian 12. If your XOA is using an earlier version of Debian, then you should deploy a new instance of XOA to switch to the newer Debian version.

@Forza This isn't needed because the XOA VM is already performing these OS updates using unattended-upgrade.

For deployment on ESXi, you need to also do the following --

sudo -s  
cd /usr/local/bin  
curl -O https://gist.githubusercontent.com/julien-f/a6f98de3bd5a775f3f04b2fa14a9a102/raw/xenstore-read
chmod +x xenstore-read

@McHenry You always have to select a template when creating a new VM. By select the template as a first step, you will avoid this type of problem.

Are the SRs listed correctly if you first select a template?

@Vagrantin Have you tried restarting the host's toolstack with xe-toolstack-restart and then try starting the VM again?

@Vagrantin Have you check the XAPI logs for errors related to starting the VM?

@cichy The docs specifically mention that you need to repair the VHD files following the rsync operation.