The “compile XOA from source” repo is maintained by @ronivay. Tom has some excellent videos describing how to make use of this - which include five to ten minute breaks for coffee while the cpu intensive compilation takes place.
In a Homelab context this had a “worthy” feeling about it. Yes, I am making use of this serious corporate product, but hey! I did not just press the install button - I had to go thru a number of steps, watch it compile etc.
But now @ronivay is also maintaining an XOA docker image (ronivay/xen-orchestra:latest) which seems to take most of the hard work out of it. I have a stand-alone server which only runs Docker - so easy to run up another container to run XOA. And with watchtower it stays up to date. As I understand with the “self compiled” option, you have to re-run the compilation to bring XOA to latest version.
Not quite cheating, but takes most of the “worthy” feelings out of it.
If starting with XCP-NG and you already had a Docker setup, this does seem an attractive option. And I suppose you could run XOA in Docker in a VM hosted on yr Hypervisor too - tho that may be more levels of abstraction than I can cope with on bad days of the week - feels like you are following instructions from British/Australian comedian Spike Milligan “open the crate with the crowbar you will find inside”.
Hmmmm… I’m working with Harvester on part of my lab… Maybe I should try loading this container into Kubernetes when I get to that point. Slow going right now while I’m working out some hardware things.
I’m not entire sure if this post is a complaint or a complement. Users might have docker VM’s in their infrastructure, yeah, it is simple to deploy the source version of XOA. Or if a ubuntu/debian VM tickles your fancy then run the installer/updater script. This container has been out for a LONG time now. I mentioned it in this post How To Build Xen Orchestra From Sources 2024 - #2 by xMAXIMUSx
The only aspect I’d point out to anyone running Xen Orchestra ‘from source’, either as docker or directly installed within their OS - remember that for any of the backup functions within XO, data will flow between XCP-ng host and Storage Repository (whether local or network), and then from XCP-ng host to the XO instance, and then from XO instance to the Backup Remote (whether local to the XO instance, or again on the network). This could introduce a performance bottleneck. Fair to say that this might not matter - the impact may be negligible for you.
TL;DR = if your XO instance has slow network or storage, it will slow down VM backups (but that might not matter)
Source or purchased appliance, the data flow for a lot of tasks is the same. That’s why it can be a good idea to attach it to the fast storage/management network to allow things to go more quickly.
But still also a good idea to keep a from sources around external from the pool for emergencies. With XO-lite getting new functions, this is less of a concern, but still a concern. I’ve had my “main” XO VM crash and corrupt a few times, and the external running on an old HP T630 saved the day. Rolling Pool Updates and other update/reboot related things I like to handle from the external XO when possible.