A hypervisor is the software layer that lets a single physical server pretend to be many, running several independent virtual machines side by side, each with its own operating system, isolated from the others. In control rooms this is how one capable server can host the SCADA server, several HMI servers, a historian, and a domain controller as separate virtual machines rather than as a rack of separate physical boxes. This guide explains what a hypervisor does, why control rooms virtualize their servers, and the difference between bare-metal Type 1 and hosted Type 2 hypervisors in an OT setting. It concerns server-side virtualization specifically, not where the compute physically lives, so it stands apart from edge and cloud-versus-on-premise questions.
Hypervisor in one line: A hypervisor is software that creates and runs virtual machines, allowing one physical computer to host multiple isolated guest operating systems at once by sharing its CPU, memory, storage, and network among them. Each virtual machine behaves as if it were a separate physical computer, unaware of the others, while the hypervisor allocates resources and keeps them isolated. Hypervisors come in two types: Type 1 runs directly on the hardware (bare metal), and Type 2 runs as an application on top of an existing operating system.
A hypervisor works by inserting a thin, privileged layer between the physical hardware and the operating systems that run on it. Instead of a single operating system owning the server's CPU cores, memory, disks, and network cards directly, the hypervisor owns them and parcels them out to virtual machines, each of which sees what looks like a complete, private computer. A virtual machine has its own virtual CPUs, its own block of memory, its own virtual disks and network interfaces, and it runs its own operating system entirely unaware that it is sharing a physical host with others. The hypervisor enforces the boundaries, scheduling real hardware to each guest and keeping one virtual machine from reaching into another's memory or storage.
This isolation is what makes the arrangement useful rather than merely clever. Because each virtual machine is a self-contained unit, a crash, a compromise, or a misconfiguration in one guest does not directly affect its neighbours on the same host, and each can run a different operating system version tuned to the software it hosts. The virtual machine is also just a set of files as far as the hypervisor is concerned, which means it can be copied, moved to different hardware, snapshotted, or restored as a unit. That property, treating a whole running server as a portable file, is the foundation for most of the operational benefits that push control rooms toward virtualization, because it decouples the software from the specific physical machine it happens to be running on.
Hypervisors divide into two families by where they sit. A Type 1 hypervisor, often called bare-metal, installs directly onto the server's hardware and is itself the base layer, with no general-purpose operating system underneath it; the virtual machines run on top of it. Because it talks straight to the hardware with minimal overhead and a small, focused code base, a Type 1 hypervisor is the choice for production servers where performance, stability, and a reduced attack surface matter, which describes most OT server virtualization. This is the category that hosts production SCADA and HMI servers, where the hypervisor is expected to run continuously and reliably for years as infrastructure.
A Type 2 hypervisor runs as an ordinary application on top of a normal desktop or server operating system, so there is a full operating system between the hypervisor and the hardware. This adds overhead and puts the reliability of the whole stack at the mercy of that host operating system, which makes Type 2 unsuitable for production control servers, but very convenient for engineering, testing, and training. An engineer can run a Type 2 hypervisor on a laptop to spin up a test HMI, try a configuration change against a copy of a server, or reproduce a problem in isolation without touching production. In an OT context the practical division is clear: Type 1 for the production servers that must run reliably as infrastructure, Type 2 for the workstations where engineers experiment. Both isolate guests, but only bare-metal is built for the always-on production role.
Control rooms virtualize for a set of practical reasons that all trace back to the virtual machine being a portable, self-contained unit. The first is consolidation: instead of a rack full of underused physical servers, each running one application on aging hardware, a couple of capable hosts can run all of those servers as virtual machines, cutting the hardware to buy, power, cool, and eventually replace. The second is hardware independence, which is quietly enormous in OT because SCADA and HMI software often has to run for a decade or more while the physical hardware it was installed on goes end-of-life. When the server is a virtual machine, migrating it to new hardware is a matter of moving files rather than rebuilding the whole system from scratch and rediscovering forgotten configuration.
The third reason is the operational safety that snapshots provide. A hypervisor can capture the exact state of a virtual machine at a moment in time, so before applying a patch or a risky change to an HMI or SCADA server, an engineer takes a snapshot and can roll straight back to the known-good state if the change misbehaves, which is invaluable on systems where downtime is costly and change windows are short. Virtualization also underpins high availability, because a virtual machine can be restarted on a different host if its original host fails, and it eases backup and disaster recovery since whole servers can be replicated as images. In a broader control architecture, virtualized on-premise servers sit alongside cloud SCADA rather than in opposition to it: a platform such as Merobix handles the hosted supervisory and data layer with its own redundancy, while a control room may still run local virtualized servers for on-site functions, and understanding the hypervisor clarifies what each layer is actually doing. The hypervisor is about how servers are packaged and made portable, independent of whether those servers ultimately live in a plant, a data centre, or the cloud.
A Type 1 hypervisor, called bare-metal, installs directly on the server hardware with no operating system beneath it, so it talks straight to the hardware with low overhead and is used for production servers. A Type 2 hypervisor runs as an application on top of a normal operating system, which adds overhead and makes it suitable for testing and training rather than production. In OT, Type 1 hosts production SCADA and HMI servers, while Type 2 is handy on engineering laptops.
Virtualization consolidates many underused physical servers onto a few capable hosts, decouples the software from specific hardware so servers can migrate to new machines by moving files, and enables snapshots so an engineer can roll back cleanly if a patch or change goes wrong. It also underpins high availability, because a virtual machine can restart on another host if its host fails, and eases backup by treating whole servers as images. These benefits matter especially in OT, where control software often outlives its hardware.
No, though clouds are built on hypervisors. A hypervisor is the software layer that runs multiple virtual machines on one physical server, and it can run in a plant control room, a company data centre, or a cloud. Cloud computing is about renting compute and storage as a service over the internet, which providers deliver largely by running hypervisors at scale. You can virtualize your own on-premise servers with a hypervisor without using any cloud at all.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.