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,

This is the expected behavior. The oldest backup will always be a full (key) backup, and newer incremental backups will be merged into this backup as you exceed the retention schedule. When you take the full backup on Saturdays, that doesn't eliminate the need for this prior full backup. Thus you end up with two full backups for a period of time.

@Nevering Have you check here? https://docs.xcp-ng.org/project/ecosystem/#-hosting

@MW6 You may be able to copy the VDI to another location so that you can access it via another VM.

Have you searched the internet for similar issues? Here's one that I found that may help you.

@coolsport00 Please stick with the documented method to be safe.

@coolsport00 These are two different features. The XCP one involves renaming the physical NICs. Any changes you make in XO doesn't rename the physical NIC.

From the error message, I would guess that there is some corruption in the XVA file. Have you tried importing it back into the original system, or maybe exporting to XVA again and then retest?

@RaHu Your are correct. To delete an individual snapshot, change /vms/ to /vm-snapshots/.

What about using a web hook to vm.create and vm.delete?

Hi Yusuf,

I extended your trial period.

Regards,
Dan

@fdhabhar You may want to review our VMware migration checklist.

From the VMFS6 section --

- Uninstall VMware tools before migration.
- Remove all snapshots attached to the VM.
- Be sure you don't have any ISO mounted to the VM.
- Shutdown the VM.
- take a fresh snapshot.
- Start migration.

Any locks should be automatically removed once the migration is complete as long as you follow these steps. To manually release the lock, you can restart the xo-server server in XO.