Tested with Chrome now, on chrome it works. So it seems only a firefox problem. I switched off the extensions ( https everywhere, ublock origin and privacy badger ) but still crashes. Had htop running on my client while crashing, no unusual increase in RAM usage while going to crash. Rebooted XO VM, now it is ok again with firefox. so for me the issue is closed, if somebody is bored and wants to look into some logs for bug hunting i am glad to provide them. i also restarted the toolstack on one of the pool members ( not master ) and the "no such host" error is gone.

xe CLI. Type xe --help.

@sborrill I have a work-in-progress branch with a plugin for this: https://github.com/vatesfr/xen-orchestra/pull/4701 To test, you will need to checkout this branch, add a symlink to the packages/xo-server-auth-http plugin into the directory xo-server/node_modules and then to configure and unable the plugin from XO. This will make basic authentication available with the path /signin/basic, note that you can make it the default authentication by overriding authentication.defaultSignInPage in your configuration file. julien-f opened this pull request in vatesfr/xen-orchestra open WiP: feat(xo-server): support HTTP basic auth #4701

Will do. I've got an installation of it in two locations and neither are behind a proxy. In a moment of early-onset senility/dementia I confused npm with dnf - somehow! So there's obviously a chance I'm doing something incorrectly.

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