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. In this way, it can listen and record every event occurring on your whole Xen infrastructure. Connections are always open and it can cache informations before serve 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 lost of resources and bandwidth waste with a central point:
Legacy interfaces use the "pull" model, requesting data every "x" seconds:
It's not scalable and slow.
With XO < 3.4, we used events in this way:
But interface was still lagging behind the server. With XO 3.4, we got 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. It 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 a 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 better:
To install a patch manually, you need a lot of steps: find, download, extract and apply the patch, sequentially.
"xo-server" can do all these steps once:
- downloading automatically the patch on Citrix servers
- unzip it and uploading it on the fly to your host
- apply it as soon it's done
It's really easy to plug 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.