@olivierlambert @stormi is the one who helped me find and fix the issue. I just wanted to update my old thread in case someone else happened across the problem until it gets fixed in XO.

No attached disks so far, but I'll wait until next week to bump up the NBD connections to make sure.

Currently, there is a concurrency setting for backup jobs. However, it is only how many VMs to backup at the same time.

I think being able to have more granular options would be helpful. For example, being able to specify per host, so that you could do multiple backups at once without bogging down a particular host. The same with doing snapshots vs transfers.

Thanks.

@Danp From what @florent stated in the other thread, it should be fixed, but I'm having it happen on every backup so he's looking into it again.

@KPS A notification would be handy, but I'm mainly just looking for a way to manually tell. A simple list of changed files and size delta would work.

I don't want to do a whole third party agent such as suggested by @DustinB as the issue isn't caused by the typical cases he listed. One of the VMs is Windows and spends 90% of it's time idle. I'm assuming the large deltas are caused by various background updates but it would be nice to know for sure.

@olivierlambert I'm glad to hear it's on the roadmap. Vates has been pretty responsive IME so I look forward to it's eventual rollout.

@olivierlambert Are we still waiting on @ManonMercier to provide more information?

This ended up causing xen to get stuck in a boot loop during an 8.3 update. During the troubleshooting of that, we determined that XO had never correctly deleted the reference to the SDN cert.

If you run into this problem or something similar, run this comment.

xe certificate-list

You should see one of the certificates show with the following.

name ( RO): sdn-controller-ca.pem
host ( RO): <not in database>

If the certificate file doesn't exist, you will have to recreate it before you can delete the cert reference.

touch /etc/stunnel/certs/sdn-controller-ca.pem
xe pool-certificate-uninstall name=sdn-controller-ca.pem

This should fix the problem.

@postal2201 XO-Lite is still a work in progress. Use the xe command line or deploy a Xen Orchestra VM. You can one click deploy XOA from that button in the corner and either use it as is or use it to build a VM with XO from source.

I started on XCPng with AMD mini PCs for the same reasons you're looking at them. While compute and memory were fine, the lack of faster networking made me switch away from them.

If you're managing things proxmox style with all local storage, then they work well. But that means that you lose out on a lot of the nicety of XCPng. Rebooting a host means that you either wait for a migration to another node or shutdown/suspend the VMs. Using shared storage typically limits you to 1G or 2.5G speeds, which mean your VMs have half the speed of SATA.

I've since moved to using older desktops for my hosts. I can max out their memory relatively cheaply and easily add a 25G or better NIC. While the setup uses more power than the mini PCs, it's actually not bad. IIRC, typical usage was around 20W. But as I mentioned, I'm not doing any heavy compute workloads.

@TheRedHerring I have an HM90 that I use as a host and it worked with 8.2 out of the box except for the 2.5G NIC. I switched to 8.3 and everything worked out of the box.

@stormi Uh, how do I do that?

Also, I think the problem may be due to when I was attempting to set up a private network. I had deleted all of that but it seems to be stuck in a loop trying to find sdn-controller-ca.pem. Therefore the update never completes and it just tries again.

@stormi I have not rebooted the server at all. I told it to apply patches and then this all happened.

I didn't want to reboot it in case it was in the middle of something or if there were things you wanted me to check.

I'll try rebooting it and see what happens. Hopefully the other pools and nodes won't have this issue.