The ability to access any VM or host console is not new in Xen Orchestra. It works almost from the beginning (well, sometimes with somes glitches). You can see an example here:
Let's recap the global architecture to have a better understanding:
Since the start, it works like that (let's call this "the XAPI's way"):
xo-web(your browser) asks the console to
xo-server(the XO daemon)
xo-serverasks to XAPI URL of the VM console
xo-serversends the VM console URL to
xo-webconnects directly to this VM with noVNC
And thus, lead to these problems:
- XAPI only exposes plain communication (no encryption for websockets): that's why HTTPS in XO and console were incompatible, like explained in this issue.
- Consoles can't work outside the network (e.g NAT,
xo-serverwill send a private class IP address to your
xo-webwhich is outside: it will fail). Reported in this issue.
- And finally, it was a securiry concern: currently we expose the session identifiers used to connect to pools to
xo-web, this can able any users to access any connected servers.
Exactly the problems was also reported in our forum, here, here or here.
That's why, building a "console proxy" through
xo-server was in the top of our roadmap! In this case, you can use
xo-server to expose all your XenServers, even if they are behind a NAT, without any problem to display their VM consoles! It's also secure, because token are kept right in
xo-serverand never sent to the client.
And... it's done!
We just managed to do that proxy thanks to these commits, it's currently in the
next-release branch for further tests, but will be in the 3.7, which will be out soon!