Wednesday, February 4, 2015

XO Console from everywhere! [feedly]



----
XO Console from everywhere!
// Xen Orchestra

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-server asks to XAPI URL of the VM console
  • xo-server sends the VM console URL to xo-web
  • xo-web connects 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-server will send a private class IP address to your xo-web which 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!


----

Shared via my feedly reader


Sent from my iPhone