Looking at the cli output this sounds like a classic confusion of how memory is used in linux. As you can see from free command output, you actually have majority of the memory still available. Graph in XO doesn’t tell much how the memory is actually being used so it might be confusing as most of it is in cache and buffers which usually is something that can be released into use immediately if an application needs ram.
I can give my nails cut for the fact that this is due to the overall slowness between the xcp-ng and XOA.
I've been having similar issue and was pulling my hair, in a usecase where my xcpng was on the other side of the VPN wire, and the virtual console of the VM, could not be drawn on time to allow me hitting any key to run the content within the mounted iso. (in my scenario I I've been using xcp-ng centre)
this issue become the relict of the past, when I did the same thing within my network (still over the vpn but utilizing a RDP of the machine within the LAN network).
maybe apache quacamole will do the trick for you, to expose some way of reching it out.
think about it.
ps. I've been having this with BIOS / UEFI, at first place I thouht this is an uefi, but it was not.
@bberndt the sdn controller communicate with the hosts on port 6640, opening it on the host should be enough.
I don't know what's happening. !this TLS error should have been solved by the override-certs option set to on.
Not sure i fully understand your question so let me clarify some points and perhaps you can ask some questions after that.
XO allow you to make backups to what we call a remote, this remote is a network share (or local but not recommended) inside the XCP network where you can store your backups.
You can also backup XCP metadata this allow you in case of a major crash of one of your host to restore the host configuration.
Once your backups are setup you can restore them directly from your XO.
If you want to protect further your data you could copy your backup to another place but it's not directly include in XO even if you could set two remotes for the same backup job and have you backups directly replicated
I say this because, monitoring the process, everything seems to be going well until the moment when it starts to check the free space.
XCP-NG is 8.2 up to date, the disk on which the VM is it is formated as local ext.
The connection to the backup server is on NFS on the LAN at a speed of 1Gb.
On the iotop it seems that the space check goes with speed 650Gbits +.