Architecture

##Current architecture

In the picture bellow you can see the current architecture of plainvm.

Let me introduce you the main elements.

• End point - the host where the Virtual machines are located
• Entry host - the host which accepts the clients, collects and provides information for the Virtual machines. This is also the place where the HTTP server is located.
• Client - a thin client, browser which supports HTML5 and WebSockets.

###Communication

In this sub-section I'm going to introduce the main methods of communication between the different hosts on the diagram.

When an End point is being started it starts to listen on port 5000 (by default, it could be easy changed from the configuration file). On configurable period of time the End point checks for modifications on the virtual machines which are located on it. On separate interval of time plainvm's End point makes screenshots of all started machines, resize them and puts them into the cache. When the client (in this case Entry host) requests updates the data from the cache is being provided.

When the Entry host is being started it reads all associated with it End points from a configuration file (endpoints.conf) and try to connect to them on port 5000 by default (or customized one). When the connection to all End points is established the Entry host starts polling in configurable intervals of time (1 second by default). The Entry host has cache which is updated when there are changes in the screenshots, state or properties of any virtual machine located on any host (End point). The polling is happening directly through TCP socket connection.

When the Client connects to the Entry host the Entry host provides all required resources which are permitted for the client (html, css, javascript files, etc.) and establishes a websocket session with the Entry host. The HTTP server can provide only files which are listed in a hash map located in the Entry host. Through the websocket session all updates on any virtual machine on any host are pushed to each clients which have established websocket connection with the Entry host.

As you see from the diagram there's also a direct RDP session between the client and any of the End points. It's not exactly RDP, it stands only for clarity, the actual protocol is guacamole. This is optional and only happens when there are all dependencies installed for remote control of the virtual machines and the client requests a connection.

There's direct access to the End point because of performance considerations.

####Communication protocol

For data serialization the communication protocol uses JSON.

#####Client <-> Entry Host

All messages used for communication in plainvm has the following format:

{
    "type": "type of the message",
    "data": "data to be transmitted", //optional
    "action": "action to be performed" //optional
}

Request types for management over the VMs are:

1. system-update - sends update to the client
2. system-screenshot-update - sends screenshot updates to the client
3. system-startup-init - initializes the client (client connect for first time)
4. change-vm-state, with action property - used for control over the VMs on the End points
   • start
   • poweroff
   • shutdown
5. machine-edited, with data property - used for control over the VMs on the End points
   • updated serialized VM

As you see all messages with types in 4 and 5 aims control over the VMs on the End points. They are just transmitted to the End point.

#####Entry Host <-> End Point

For that communication is used message with the same format as above. It's simplified and has the following attributes types:

1. update, request/response for update by the Entry Host
   • data property if it's a response
2. screenshot-update, request/response for screenshot update by the Entry Host
   • data property if it's a response

All responses have data attribute with the data provided by the End point.