XO-Server is the core of Xen Orchestra. Its central role opens a lot of possibilities versus other solutions - let's see why.
As a daemon, XO-Server is always up. Because of this, it can listen and record every event occurring on your entire Xen infrastructure. Connections are always open and it can cache information before serving it to another client (CLI, Web or anything else).
Contrary to XenCenter, each Xen Orchestra's client is connected to one XO-Server, and not all the Xen servers. With a traditional architecture:
You can see how we avoid a lot of resource and bandwidth waste with a central point:
Legacy interfaces use the "pull" model, requesting data every "x" seconds:
It's not scalable and slow.
Previously with XO < 3.4, we used events in the following way:
But the interface was still lagging behind the server. With XO 3.4 and beyond, we now have a full event system, allowing instant display of what's happening on your infrastructure:
XO-Server will act as a proxy for all your clients. This opens a lot of possibilities!
A good example is the console: you can now expose your consoles even if your clients are outside the network!
Another possibility is to stream a VM from one host to another.
To do that previously, you needed to export your VM somewhere, then re-import it:
Thanks to our architecture, it's now far easier:
To install a patch manually, it requires a lot of steps: find, download, extract and apply the patch, sequentially.
"xo-server" can do all these steps at once:
- automatically download the patch from Citrix servers
- unzip it and upload it on the fly to your host
- apply it as soon it's done
It's really easy to connect other modules to XO-server, and extend or adapt the solution to your needs (see XO-web and XO-cli for real examples).
An API is available to communicate directly with XO-Server. This part will be explained later.