Virtualization saves money partly because most virtual machines do not use all their assigned resources all the time, so a host can promise more CPU and memory to its VMs than it physically owns and get away with it. That practice is called overcommit, and for ordinary office workloads it is efficient and harmless. For a real-time SCADA VM, though, overcommit can quietly starve the one machine that must never be late, causing missed polling scans that look like network problems but are really the hypervisor rationing cycles. This guide explains what CPU and memory overcommit are, the ballooning and CPU-ready pitfalls that hurt control workloads, and why the SCADA and historian VMs need reservations and pinned resources.
VM resource overcommit in one line: VM resource overcommit, also called oversubscription, is when a virtualization host allocates more CPU or memory to its virtual machines than it physically has, betting that they will not all demand their full share at once. It is efficient for bursty workloads, but it can starve a real-time SCADA VM of cycles when the host gets busy, which is why control VMs need guaranteed reservations rather than relying on the host to share fairly.
Overcommit exists because most virtual machines are idle most of the time. A host with, say, sixteen physical CPU cores might hand out the equivalent of forty virtual cores across its VMs, on the reasonable assumption that they will rarely all be busy simultaneously. The same logic applies to memory: the host can promise more RAM to its VMs than it physically has, backing the shortfall with clever reclamation techniques, because at any given moment much of the assigned memory sits unused. When the bet holds, the site gets far more consolidation from the same hardware, and that is real money saved.
The bet is statistical, and it works because bursty, uncorrelated workloads rarely peak together. An office file server, a print queue, and a reporting database are each busy at different times, so overcommitting them is safe. The trouble is that overcommit assumes any given VM can tolerate waiting a moment for its turn when contention does spike, because for most software a few extra milliseconds of latency is invisible. That assumption is exactly the one a real-time control workload violates.
A SCADA server runs on a clock. It must poll its field devices, process the responses, evaluate alarms, and update the historian within a scan cycle that repeats on a fixed cadence. If the hypervisor makes the SCADA VM wait for CPU because it over-promised cycles to other VMs that all got busy at once, the scan runs late. To an operator that looks like a device going unresponsive or a comms glitch, but the real cause is that the control VM lost a race for physical cores it was never actually guaranteed. Overcommit that is invisible to an office VM becomes a missed scan for a control VM.
Two specific mechanisms explain most overcommit-related SCADA problems. The first is memory ballooning, the technique a host uses to reclaim RAM it over-promised. A small driver inside each VM can be inflated on demand, pressuring the guest operating system to give memory back to the host so it can be handed to a VM that needs it more. Under memory pressure the host inflates the balloon in the SCADA VM, the guest starts paging to disk to cope, and a machine that should be servicing a scan is instead swapping memory - a slowdown that is easy to misdiagnose because the VM still reports plenty of assigned RAM.
The second is CPU-ready time, the interval a virtual CPU spends ready to run but waiting because no physical core is free. On an uncontended host, ready time is negligible. On an overcommitted host under load, a VM's virtual CPUs queue for scarce physical cores, and that queuing shows up as ready time. For most VMs a little ready time is harmless, but for a SCADA VM every millisecond of ready time is a millisecond the scan is delayed, and if ready time climbs, scans start slipping their deadlines. Monitoring CPU-ready is often how virtualization-savvy OT teams catch a control VM being quietly starved.
There is a subtler trap with wide VMs. If the SCADA VM is configured with many virtual CPUs, the hypervisor may need to line up that many free physical cores at the same instant before the VM can run, and on a busy overcommitted host those cores rarely free up together, so a wide VM can wait longer than a narrow one. Giving a control VM more virtual CPUs than it needs can therefore make its latency worse, not better - one of the counterintuitive pitfalls that makes overcommit tuning for real-time workloads different from tuning ordinary servers.
The cure is not to ban overcommit outright, but to exempt the workloads that cannot tolerate it. Hypervisors provide reservations, a guarantee that a VM will always get at least a defined amount of CPU and memory that the host sets aside and never overcommits. Reserving the SCADA and historian VMs' resources takes them out of the statistical pool: no matter how busy the other VMs get, the control VMs have a floor of physical resource that is theirs. That floor is what keeps scans on time while the rest of the host stays efficiently overcommitted.
Two related controls help. Shares set the relative priority a VM receives when the host has to arbitrate contention, so raising the SCADA VM's shares makes the scheduler favor it over lower-priority neighbors during a squeeze. CPU affinity or pinning ties a VM's virtual CPUs to specific physical cores, so the control workload is not bounced around and does not have to compete for whichever core happens to be free. Reservations guarantee the amount; shares and pinning shape how and where the VM gets served. Together they turn a shared host into one where the control VMs behave as if they had dedicated hardware.
For cloud SCADA, this whole class of tuning concern moves off the customer's plate for the primary monitoring layer. When a platform such as Merobix runs the SCADA and historian workload in a managed cloud environment, the resource guarantees, capacity headroom, and performance isolation are the provider's responsibility, engineered so ingest and dashboards stay responsive under load. On-premises hosts still need careful reservation and pinning for any local control VM, but the field-facing monitoring that operators watch does not hinge on someone remembering to reserve CPU for the SCADA VM on a shared box back at the site.
Overcommitting the host is fine for the non-real-time VMs on it, but the SCADA and historian VMs should be protected from it with reservations so they always get guaranteed physical CPU and memory. In other words, you can still overcommit the office-style workloads to save money, as long as the control VMs are carved out with a guaranteed floor. Overcommitting the control VMs themselves risks missed scans when the host gets busy.
Two common overcommit culprits are memory ballooning, where the host reclaims RAM from the SCADA VM and forces it to page to disk, and high CPU-ready time, where the VM's virtual CPUs wait for busy physical cores. Both delay the scan cycle and can look like a comms fault. Setting resource reservations and monitoring CPU-ready time usually resolves and diagnoses the problem.
Memory ballooning is how a hypervisor reclaims memory it over-promised. A driver inside each guest VM can be inflated to pressure that guest into releasing memory back to the host, which then redistributes it to VMs that need it more. It works quietly for idle VMs, but ballooning a busy SCADA VM forces its guest to page to disk, slowing the control workload even though the VM still shows plenty of assigned memory.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.