There are a plethora of ways to connect to a remote system, from command-line based protocols like SSH, to graphical user interfaces such as RDP. One of the simplest ways to connect to the GUI of a remote system is via VNC (Virtual Network Computing), which transmits keyboard and mouse events from one computer to another, relaying screen updates back by returning a sequence of pixels which when put together produce an image or ‘frame’. Simply put, it allows one computer to delegate its GUI display to another machine for the sake of convenience. VNC is built upon the Remote Frame Buffer (RFB) protocol, which works at the framebuffer level (a point in a system’s memory which contains the details for the GUI display). This allows it to work across most operating systems and applications.


(Old VNC-based console)


The RFB works in a client-server model. The remote user is the RFB client or viewer, and the endpoint where changes to the framebuffer originate (i.e. the system and applications) is known as the RFB server.

The efficiency and simplicity of this approach, along with its native support in KVM and XenServer, led to VNC’s adoption in CloudStack, allowing users to remotely access their virtual machines via a browser.

The user’s keyboard and mouse events are sent via API calls to CloudStack, which transmits them to the virtual machine. It then fetches the frames from the virtual machine, renders them into images, and via API calls displays these images in the browser as tiles, which when combined, renders the entire display.

Although this approach works well, network latency, as well as multiple continuous API calls, can reduce performance and User Experience. It leads to delays in events being propagated to the virtual machine as well as the partial rendering of the display.

Enter noVNC! noVNC is both an HTML VNC client JavaScript library, and an application built on top of that library, and runs well in any modern browser (including mobile browsers). noVNC follows the standard VNC protocol, but unlike other VNC clients, it leverages the bi-directional communication of WebSockets to do the heavy lifting and transfers the task of rendering the display to the client. Now all keyboard / mouse events are transmitted over this WebSocket (created specifically for communication to the virtual machine) and the frames to be displayed are transmitted back to the browser, eliminating all API calls to CloudStack. It also natively supports various keyboard layouts when configured in the remote machine. This reduces the application overhead, allows for real-time rendering of the virtual machine’s console, and provides a superior and uninterrupted user experience.


(no-VNC console)


noVNC will be introduced in the CloudStack 4.15 LTS release and will become the default console, controlled via the ‘novnc.console.default’ global setting. More information on noVNC can be found at