@AgentZoy Sorry, but I don't understand your current issue. Please restate.

This is not related to the original, feel free to create a new one regarding this issue. You can't "manually" move a VM, there's always a client to do that (XO, xe, XCP-ng Center etc.). So you need to understand why it's failing first.

It should work on XS 6.5, yes. Feel free to create a ticket if you need assistance

@Biggen Ahh gotcha. I’ll check that out

@Danp The implementation would be very different

Repair is just replug the pbd. Of course you can do that with XO

Okay thanks for the feedback

But now release xo-server 5.53.0 backup export concurrency >2 didn't apply. Setting concurrency to 4 or 6. but only 2 tasks works at the same time. Reverted to release xo-server 5.52.1 then 4 and 6 concurrency tasks are shown as expected.

@bill-gertz It depends of how you install it, but it look ok. In our appliances we install and run xo-server as a global service, and there is only /etc/xo-server/config.toml which is used for user customization (you could remove it and it would still work).

I can put the script everywhere - but I want to avoid non standard config. In case of failure of {system} I'm reinstalling it, and restoring config from file. I don't need to remember that I've put some fancy staff somewhere on the lan.

@Danp thanks for responding. Your suggestions are very good, caused me to check other things and reveal some things: My metadata and XOA config backups have started to fail with the error 'no such object' The metadata/config backup job's pool parameter was highlighted red with a warning symbol, showing a long GUID style id. I could not update the pool parameter - I have the spinning circle (of doom). After deleting the metadata/config backup job, I cannot recreate it - similar problem with pool parameter, none shown plus spinnng circle (of ongoing doom). To cut a story shorter - I think I have fixed my problem by re-attaching the hosts/SRs to my XOA-community VM... Then I also noticed that the 'successful' backups are not successful as when I looked at their logs by clicking on the green 'successful' indicator in the backup logs I see they are skipping missing VMs. Terrific. So I have now updated all the jobs and reselected each VM, saved them and then re-run the backups. So my big concern (understatement) is my XOA host VM backups have gone bad without any external changes, other than my applying XOA community updates. Do I need to check the backups carefully after every update? Surely not? Perhaps my method of updating, by running a script is horribly HORRIBLY flawed?? I found and have used an update script by Jarli01, applied as noted here. I've got a script to pull the latest update script and execute it. Not clear if I should inbclude the '-b stable' parameter. #!/bin/bash sudo curl https://raw.githubusercontent.com/Jarli01/xenorchestra_updater/master/xo-update.sh | bash To answer your useful questions: Q. When did you last pull from the source? A. Assume you mean 'when did I last retore from the backup volume'? Never. This is a first time for me. Q. What type of SR(s) should be showing? A. I have two: a local xcp-ng host (also hosting the XOA-community VM being used) and a remote xcp-ng host. Although it does seem an SR is an xcp-ng host, I am confused to the nomclature of 'SR' - I will try to find that out with Google ;). However, as mentioned above my hosts had disconnected themselves... WTF? Q. Are you able to target an SR when defining a new backup job? A. No! OMG. Also noticed the VMs have stopped being shown, no hostts connected!! WTF? Q. Have I opened dev tools (F12), checked console for errors? A. No, but I will when I next report something. Checking the backup page today I do get an error in index.js. I am happy to debug more and return trace/debug data if it is useful; below is what I see today on the backups page: [React Intl] Error formatting time. RangeError: date value is not finite in DateTimeFormat.format() index.js:525 Z index.js:525 formatTime index.js:719 value index.js:1168 React 81 _renderOverlay Portal.js:84 componentDidMount Portal.js:47 m factory.js:665 React 12 notifyAll close closeAll perform perform perform S closeAll perform batchedUpdates batchedUpdates dispatchEvent Q. Check system logs? A. Assume you mean from xoa vm? I will include those next time I post - when I find where they are. Google will no doubt help me out there.

I have isolated the problem. The issue was with dynamic memory allocation on our test server. This was definitely a localized issue. Cheers

@olivierlambert https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-uri a plain rpd://ip-address seems to work fine in Mac OS and iOS but more information may be needed on windows clients not sure if the uris work on all systems the same. EDIT Looks like windows doesn't support URI to RDP but Microsoft makes it work for basically every other OS. I still think its a worthwhile feature even if it is slightly less functional because Microsoft is weird.

Normal backup jobs. In this case it is the "full" copy of the VDI I just moved to a local SR (due to maintenance on the NFS) I mentioned here https://xcp-ng.org/forum/topic/2247/moved-vdi-delta-backup-restarts-on-full. I see that Control Domain load is high and in top I see this: [image: 1574324430375-ea0c91a9-d64d-4403-b97e-e00103b6f7a2-image.png] At the moment it is only one disk left to transfer, but there were 3 to start with, so the load was higher in the beginning.

OH ok. Hope you can prioritize this soon

Your CR issue might be related to a XO bug on master, not too a XCP-ng issue

Sorry, I was trying to execute the git command in the wrong directory, my bad. Everything worked perfectly, the restores worked now. Thank you very much @Danp.