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

@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.

Click the person icon below the Sign Out option to access the settings for the currently logged in user.

This should be recoverable, but it can be difficult to troubleshoot this way. Have you investigated the BAD_POWER_STATE error? From your first screenshot above, it looks like the VM is suspended, not stopped. Have you tried starting it with xe vm-resume?

@TechGrips I'm simply trying to provide assistance. It easy to misinterpret a forum post, so let's just chalk it up to a miscommunication.

@TechGrips said in How to do Simple Backup to Local USB Drive?:

I've done that, many times actually, as I mentioned in my original post.

Hmmm... I must have missed that in my quick review of your OP. Checked again, still don't see where you mentioned trying to create a local BR.

Create a local backup remote under Settings > Remotes. Then use it as the target for your backup jobs.

The memory usage being reported may be incorrect due to the way Node uses memory. I see kswapd0 with high CPU usage in your screenshot, so that is a clear indicator that swapping is occurring. Give the VM 16GB again and the issue should resolve itself.

Yes, the default timeout for XAPI tasks is 24 hours. This can be modified as explained in the documentation -- https://docs.xcp-ng.org/management/manage-locally/api/#24h-task-timeout

Your backup won't be affected if the VM is rebooted while the backup is running.

@kagbasi-ngc Try changing ({name}) to {{name}} in your user filter

Isn't this the same issue caused by the Node upgrade? https://github.com/nodejs/node/issues/54359

notr1ch created this issue in nodejs/node

closed Happy eyeballs implementation times out prematurely #54359

@kagbasi-wgsdac You can monitor the XO logs by issuing the command journalctl -u xo-server -f -n 50 and then retrying the export from within XO.

You could also check the logs on the XCP host -- https://docs.xcp-ng.org/troubleshooting/log-files/