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.

@kruess I can see numerous instances of VM_HOST_INCOMPATIBLE_VERSION in your xensource log. It is difficult to know the exact cause ithout more details.

• Was the pool master restarted after the patches were applied?
• Are you trying to start the VM on the master?
• Are you upgrading directly from XS 7.1.2 to XCP 8.3?

@User-cxs You are probably experiencing this issue.

Just a guess because you didn't actually ask a question.

@edsilber said:

you have held broken packages

Have you tried running yum clean and then retrying the install process?

You are running XO from sources, correct? What OS version?

Edit:

Oh, I see you are running a very old deployment of XOA. Deploy a new instance of the appliance and then the package issues will be resolved.

@User-cxs Are you saying that the initial problem was due to the appliance not being registered?

@User-cxs Can you show us the output of ip a on your XOA VM?

@ph7 Do you know which commit you were on previously? Also, it may help if you can share the full backup log.

Hi,

You may want to follow this thread for the VDI not visible issue.

Dan

Just go to Settings > Servers tab in XO and remove the entry associated with this pool.

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

@Bytevenidos You can try that, but it most likely won't work.

I've confirmed with the dev team that the end point to mount an ISO doesn't currently exist for the REST API. However, it does exist in the older JSON-RPC API, which you can access using xo-cli --

vm.insertCd id=<string> cd_id=<string> [force=<boolean>]