Ravada: a web console for running KVM desktops on a cluster

What Ravada is, and who it is for

Ravada is an open-source project providing a web-based user interface for managing and accessing virtual machines based on the QEMU and KVM virtualization technology. The stated aim is to simplify the management of virtual machines by offering a user-friendly interface accessible through a web browser, and the stated audience is specific: sysadmins who have some background in GNU Linux and want to deploy a VDI project. That framing matters, because Ravada is a virtual desktop infrastructure manager, not a console for one machine. Users can create, configure and manage virtual machines without a dedicated desktop client, and the features include remote console access, snapshot management, and the ability to manage multiple machines from a central interface. The requirement on the client side is deliberately minimal: a web browser and a remote viewer supporting the SPICE protocol.

The two resource types: shared machines and per-user clones

The feature list contains the two things a VDI project actually needs. There is a KVM backend for Windows and Linux virtual machines, which is the shared-machine case, and there are light and fast virtual machine clones for each user, with instant clone creation, which is the per-user case. A deployment typically mixes the two, and the design of the per-user clone is the part that determines whether a VDI project is viable, because a copy-once-then-clone approach turns a thirty minute image build into a few seconds of disk space per user. The other features are the ones that make a shared machine usable as a workstation: remote access with SPICE for both Windows and Linux, USB redirection so a physical device can appear inside the guest, kiosk mode where a user gets the machine without a menu, and an easy and customizable end-user interface with administration from a web browser.

Authentication, and the hypervisor assumption

Two design decisions are worth pulling out because they shape what you can build on top of Ravada. The first is that authentication supports LDAP and SQL, so a deployment can plug into an existing directory or a database of user records rather than maintaining accounts inside the tool. The second is the back end. Ravada's back end has been designed and implemented to allow future hypervisors to be added to the framework, which is the right way to structure it, but in the current release the KVM hypervisors are used as the backend for the virtual machines. So the framework is ready for more and the reality is one hypervisor, and a plan that assumes Xen or VMware support has to wait for that work to land. The current release line also makes the version scheme worth noting, with the release tags showing v2.4.6 on 2026-05-27, v2.4.5 on 2026-02-26 and v2.4.4 on 2026-02-06, while a version badge in the project overview still reads 1.8.0.

The REST API and its OpenAPI file

Ravada provides a REST API for programmatic access to its functionality, and the documentation is a real OpenAPI 3.0 specification, stored in the repository as openapi.yaml and described as the complete API documentation for the frontend endpoints. The overview suggests three ways to work with it. You can paste the contents of openapi.yaml into the Swagger Editor for authoring, use Redoc for a cleaner documentation view, or use Swagger UI for interactive API testing. What matters for an integrator is that the specification is a file in the repository rather than a page on a website, so it can be diffed, reviewed in a pull request and pinned to a version, and so a client can be generated from it. The repository also carries an openapi.yaml next to a package.json, which is an unusual pairing in a Perl project and tells you the front end is a separate asset tree with its own manifest.

The front end is an AngularJS application, and that is the constraint

The package manifest for the browser client names the project RavadaVDI at version 0.3.1 and lists a dependency set that dates the front end precisely. Angular is pinned at 1.8.2, with angular-animate, angular-aria, angular-material, angular-messages, angular-resource and angular-sanitize all at 1.5.5. Bootstrap is at 4.3.1 or later, jQuery at 3.5.0 and jQuery UI at 1.11.1, with ckeditor for rich text, font-awesome5 for icons, intro.js for the guided tour, morris.js and raphael for charting, and popper. These are the end-of-life AngularJS 1.x packages, so this is a legacy front end that still works rather than a modern framework. For an operator that is irrelevant, and for someone who wants to write a new interface against Ravada's API it is a significant fact, because the REST API is the sane integration point and the existing UI is not a platform to build on.

Installing, operating and the documentation split

There is no single install command in the project overview, and the documentation is organised by task instead. The INSTALL page is the entry point, and there are per-distribution pages for Ubuntu, Debian, Fedora, Rocky Linux 9 or RHEL 9, and Ubuntu Xenial, plus a separate page for production fine-tuning guidelines and another for operation. The operation documentation covers the routine tasks, with links for creating users, importing existing KVM virtual machines, viewing all the rvd_back options, and the admin operations section. The update page is separate again, which is a sensible split for a system that has to be upgraded without a window of downtime. The documentation is hosted on readthedocs, and the site is also reachable at ravada.upc.edu.

The project shape, and the licensing question

The repository is a conventional Perl distribution with a Makefile.PL and a MANIFEST, a lib/ directory, a t/ directory for tests, template directories, a plugins/ directory, a sql/ directory and a script/ directory, and there are packaging directories for Debian and for a docker-based setup. There is a CHANGELOG.md, a SECURITY.md, a CONTACT.md, a CONTRIBUTING.md and a pull request template, and the project follows Conventional Commits, which is a stronger signal about how a project expects changes to be described than most. Translation is handled through Weblate, and the project carries a status badge describing itself as active, having reached a stable usable state and being actively developed, with the last push to the repository on 2026-10-20. The licence is AGPL-3.0, and the package manifest for the front end repeats it as AGPL-3.0-or-later. That is the detail to look at before you deploy it on a network, because the AGPL reaches out to users interacting with the software over a network, which for a web based management console is most of your administrators.

Editorial conclusion

Ravada fits a sysadmin with a GNU Linux background who has to deploy a real VDI project, since it is a server-side manager rather than a client, it supports Windows and Linux guests on KVM, and it has the operational documentation for user creation, importing existing machines and fine tuning a production deployment. It does not fit a developer who wants a modern single page application front end to extend, because the browser interface is built on AngularJS with a package manifest that pins Angular 1.8.2, and it does not fit a deployment on a hypervisor other than KVM, since the back end has been designed with the intent of adding hypervisors later but the current release uses KVM as the backend. Before you install, work through the INSTALL page for your distribution and the production fine-tuning guide, and read the openapi.yaml specification before you script against the REST API, since that file is the authoritative description of the endpoints.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. UPC/ravada on GitHub