Virtual desktop infrastructure, or VDI, moves the operator's desktop off the machine in front of them and into a data centre, streaming just the screen to a simple device on the desk. Instead of each control-room workstation being a full computer that must be maintained individually, the actual desktop runs as a virtual machine on central servers, and the physical device becomes little more than a window into it. For control rooms this architecture brings some genuinely useful properties: operators can move between seats freely, security and patching are centralized, and recovering from a hardware failure is trivial. This guide explains what VDI is, how it differs from plain remote desktop sessions, and the important choice between persistent and non-persistent desktops.
VDI in one line: Virtual desktop infrastructure (VDI) hosts each user's desktop as a virtual machine on central servers and streams the display to a thin client on the desk, sending only screen, keyboard, and mouse over the network. This centralizes management, security, and data so the endpoint device holds nothing important. It differs from simple remote session hosting because each user gets a full, isolated desktop rather than a shared session on one server.
In a VDI setup, the desktops that operators use do not run on the devices at their seats. They run as virtual machines on servers in a data centre, and each device on the desk is a thin client, a small, low-powered unit whose only job is to display the remote desktop and relay keyboard and mouse input. Over the network travel only the display updates and the input events, not the applications or data themselves, which stay in the data centre. From the operator's point of view it feels like using a normal computer, but the computer they are using is elsewhere.
This separation of the desktop from the endpoint is the whole idea, and it is what delivers VDI's benefits. Because the real desktops live on managed central servers, IT can patch, secure, back up, and monitor them all in one place instead of tending each physical machine. Because nothing important resides on the endpoint, a failed or stolen thin client exposes no data and can be swapped for another in minutes with no rebuild. And because the desktop is decoupled from any particular seat, an operator can log in at any thin client and get their exact working environment, which is valuable when people need to relocate quickly.
A broker or connection manager coordinates all of this, deciding which desktop a given user connects to and setting up the streamed session. Behind it sits the virtualization and storage infrastructure that hosts the desktops. VDI is therefore not a single product so much as an architecture combining hosted desktops, a broker, thin-client endpoints, and a display protocol that streams the experience efficiently over the network, including handling the graphics and responsiveness operators expect.
VDI is often confused with plain remote desktop session hosting, where many users share sessions on a single server operating system, but the two differ in an important way. In session-based hosting, users each get a session on one shared server and share that server's operating system and resources, which is efficient but means users are not fully isolated from one another and cannot each have a truly independent machine. In VDI, each user gets their own complete virtual machine with its own operating system, fully isolated from other users, which is closer to giving each person a dedicated computer that happens to live in the data centre.
The practical differences flow from that. VDI's per-user virtual machines give stronger isolation and more flexibility, since one user's desktop can be configured, rebooted, or broken without affecting anyone else, and each can run software that would conflict on a shared session host. Session hosting is lighter on resources because many users share one operating system, but it constrains how much any single user's environment can differ. Which fits better depends on the needs; control rooms that want each operator position to be an independent, isolated, and individually recoverable desktop often lean toward VDI.
Both approaches stream a remote experience to a lightweight endpoint, and both centralize management, so they are cousins rather than opposites. The key question is whether users need genuinely separate machines, which points to VDI, or whether shared sessions on a common server are sufficient, which points to session hosting. Understanding that distinction avoids the common error of treating any streamed-desktop setup as the same thing, when the isolation model underneath differs significantly.
Within VDI there is a fundamental design choice between persistent and non-persistent desktops. A persistent desktop is dedicated to one user and keeps its state between sessions, so changes, personalization, and installed software persist just as they would on a personal computer. A non-persistent desktop is assigned from a shared pool built from a common master image, and it is reset to that clean master state when the user logs off, so nothing an individual does carries over. Persistent desktops feel personal but require storing a unique machine per user; non-persistent desktops are more uniform and efficient because many users draw from one template.
Non-persistent desktops fit control-room operations especially well, because operator positions are usually meant to be interchangeable and standardized rather than personalized. When every operator desktop is spun up from the same clean master image and reset on logoff, every seat is guaranteed to be in a known-good, consistent state, drift is impossible, and a desktop that develops a problem is fixed simply by logging off and getting a fresh one. This consistency and self-healing is exactly what a shift operation wants, where the tool matters more than any individual's customizations.
This layers naturally onto a cloud monitoring workflow. A control-room operator sitting at a thin client connects to a non-persistent virtual desktop, and from that desktop opens a browser to a cloud SCADA platform such as Merobix to watch every site. Because the SCADA application and its data live in the cloud rather than on the desktop, the desktop can be reset freely without losing anything that matters, and an operator can move to any seat, log in, and immediately pick up the same live view. The desktop provides a clean, secure, standardized window; the cloud platform provides the operational picture behind it, and neither depends on the local hardware surviving.
In RDP session hosting, many users share sessions on a single server operating system, so they are not fully isolated and cannot each have an independent machine. In VDI, each user gets their own complete virtual machine with its own operating system, fully isolated from others. VDI gives stronger isolation and per-user flexibility, while session hosting is lighter on resources because users share one operating system.
A persistent desktop is dedicated to one user and keeps its state and personalization between sessions, like a personal computer. A non-persistent desktop is drawn from a shared pool built on a common master image and resets to that clean state at logoff, so nothing an individual changes carries over. Non-persistent desktops are more uniform and self-healing, which suits standardized, interchangeable operator positions.
VDI lets operators move between seats and instantly get the same environment, which is valuable during shift changes or when a position must be relocated. It centralizes security, patching, and data in the data centre so nothing sensitive lives on the endpoint, and a failed thin client can be swapped in minutes. Non-persistent desktops also keep every operator position in a consistent, known-good state.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.