DevBlog #10 - Xen Orchestra Lite
XO Lite is an ongoing project revolving around a XAPI-based web application - just like Xen Orchestra, but it doesn't require you to host an appliance
XO Lite is an ongoing project revolving around a XAPI-based web application -just like Xen Orchestra- but it doesn't require you to host any virtual appliance. Each XCP-ng host will expose an XO Lite app, which will allow you to do basic management of its own pool.
During the whole development phase, we had to find a way to move fast and update often, meaning users will be able to enjoy latest bits without any specific operation. That's why -for now- XO Lite code is hosted directly on our servers.
Join the discussion about XO Lite project on the forum.
How it works
The XCP-ng host will serve a very simple HTML document (1) that looks pretty much like this:
<html>
<script src="lite.xen-orchestra.com"></script>
</html>
This loads a React JS app from our servers (2) and runs it. Which means that even though you'll access it from the host's URL, the browser will grab all the code that really matters from our servers. Once the application is loaded, it will then autonomously communicate with your host in order to manage it through XAPI (3).
Updates
This architecture will allow us to deploy XO Lite updates without you having to install the update on your host, just like a website. Your XCP-ng host will always serve the same tiny HTML document without needing to update it and lite.xen-orchestra.com will be updated by us to serve the latest version of the application.
Features
Unlike XO which has a client side and a server side, XO Lite will only run in your browser, which means everything has to fit in it and some types of features that require a server side will never be able to be implemented in XO Lite.
What's possible
Everything that's possible to do with XAPI calls, like starting VMs, creating new SRs, managing networks and much more!
You'll also be able to see and interact with VM consoles.
What's not
Since XO Lite is running entirely in your browser, it doesn't have a database nor persistent storage so it can't handle features like Users, Backups, Self Service, etc. In the end of the day, just remember there's no persistence, and it's on purpose. You can imagine that as a kind of "XenCenter from the Web".
The other difference is that's made to be a "Per pool management" tool. So if you have to manage multiple pools, then you need to have multiple tabs opened. But at this point, that's exactly when Xen Orchestra makes sense: a central tool to manage your whole infrastructure.
XO Lite & XO 6
In addition to XO Lite, we'll also be developing the next major version of XO itself: XO 6. While the 2 projects are quite different, we're hoping to be able to mutualize a lot of development efforts between them.
We decided to use React JS (a JavaScript front-end framework) not only because all the XO developers at Vates already know that framework -since we already use it for XO 5- but also because it works with components that could be reused in any other React project. So we're hoping to be able to reuse most of the self-contained components in XO 6, like modals, forms with complex logic, components used to display all kinds of XO-related data or even a tree view for VMs.
HTTPS & Self Signed Certificates
For security reasons, a client and a server should always communicate using HTTPS rather than HTTP. Furthermore, the server should use a valid SSL certificate signed by a trusted certification authority so that the client is able to know for sure that it's talking to the right server. However, getting and updating a valid certificate for all your XCP-ng hosts isn't always easy and/or worth it, depending on the network configuration. So we're aware that most XO Lite users will have a self-signed certificate on their XCP-ng hosts.
But here's the issue: if a web page tries to make an HTTPS request in the background to a server that sends a self-signed certificate, then most modern browsers will refuse to make that request. However, if you try to access a web page in HTTPS on a server that sends a self-signed certificate, then in that case, the browser won't immediately refuse it and will usually show a warning to the user, asking them if they want to bypass the certificate check and access the page anyway. If the user says yes, then the browser will remember that decision and will allow any further requests to the same origin (e.g. xcpng1.company.net).
Luckily, XO Lite will be served from the same origin as XAPI (ie your XCP-ng host), which means that, in order to access it with HTTPS, you'll first have to go through the browser warning about self-signed certificates and allow it. And once you do that, XO Lite will be able to communicate with XAPI securely and without any issues.
Console
XO Lite needs to be able to access the VMs' consoles, which isn't as straightforward as doing it from XO because of the lack of a server side:
-
XAPI's console endpoints can only communicate with raw TCP, which browsers aren't able to do yet. That's why xo-server has a WebSocket-to-TCP proxy: the browser can talk to xo-server with WebSockets and xo-server can translate it to TCP. However, XO Lite doesn't have a server side. But, conveniently, XAPI also exposes a WebSocket proxy for consoles, which is what we'll be using. XO was actually using wsproxy in the past but then switched to a proxy directly in xo-server for performance reasons. However, the performance gap doesn't seem to be noticeable anymore.
-
Another issue with using wsproxy in XO Lite is that there was a small issue in wsproxy that prevented the console from working in Firefox: in order to initiate a WebSocket connection, an HTTP/1.1 handshake needs to be made between the client and the host. However, wsproxy was responding with HTTP/1.0, which Firefox doesn't accept as a valid response, unlike Chrome. This tiny change XCP-ng team made fixed the issue in Firefox. That's another example of great interactions between XO and XCP-ng teams!
Here is a working demo of a console working directly in your browser, connected to an XCP-ng VM:
User session
How can we keep an open XO Lite session across windows and tabs that survives page reloads and can be terminated by the user? Remember that we can't create our own session mechanism like we did with xo-server since there's no server in this case.
But XAPI has its own session mechanism that xo-server itself already uses: XAPI provides a session ID on login, xo-server saves it and sends it back with every request.
So we can also use that for XO Lite: if we have a valid session ID, we can store it in a cookie and XO Lite will be considered as "logged in" until the session ID expires, the cookie expires or the user explicitly disconnects from the session, which will invalidate the XAPI session ID. XO Lite won't have a user management feature since there's no way to authenticate a user or even create an account. So the only "user" there will be is the XCP-ng host's internal root user and its password.