VTScada and Virtual Machines

It is very common for sites to run VTScada on a virtual machine (VM). If doing so (and especially for Hosted Solution sites) please note the following:

 

Running more than one virtual machine on a physical server means that the two VMs, by necessity, share resources including CPU, RAM, Disk, Networking, etc. The typical data center applications that run on virtual servers tend to include web servers and databases, both of which are heavily disk-based. But, what works well for web pages does not work so well for a control system.

VTScada requires a machine that is designed for heavy CPU-usage because it is a computational-bound application. (That is, limited by the number of computations the machine can run, more than by the speed of storage access.) Servers that are typically chosen to run VMs are those that are designed for applications such as web servers and databases rather than the VTScada-type application.

Multiple VMs on a server also share the memory bandwidth as well as the total memory size. When multiple VMs are accessing memory, delays are introduced for all due to the finite capacity of the memory to deliver data to the CPU. Disk bandwidth is similarly impacted, but will likely be less of a problem because disk loading tends to be in bursts.

VTScada can use server cores, but most activity is handled by a single core. Although physical machines can have many cores, "server class" machines tend to have much lower clock speeds than "workstation class" machines. VTScada benefits most from higher clock speeds, where 4.0+ GHz is recommended and you should avoid servers with a clock speed of less than 3.0 GHz.

There is also a minor security concern with the vulnerability known as Spectre. "Minor" because there have not been any known attacks using it so far. It theoretically allows a program running in a process to access data in another process. This includes accessing data in a different VM running on the same server. So, even if your VM is kept well protected, a compromise on another VM running on the same server could allow VTScada information to be leaked. This is not a bug in VTScada but in both Intel and AMD processors. While nearly impossible to exploit, it may be a concern for the extra cautious.

Do not attempt to snapshot a VM while VTScada is running.
Doing so will likely result in copying files that are not in a consistent state at the instant when the snapshot is taken. Any attempt to use that backup would have a high probability of having some part of the application corrupted. Attempting to use that snapshot might cause the corrupted file(s) to be distributed to all other connected workstations running the application.
Even if the snapshot is consistent, it would be out of date and using an out of date copy for a machine is highly likely to cause extensive damage to a networked application.
For alternatives, see: Backups

In summary, VTScada works well on virtual machines, but you are advised to avoid installing many VMs running VTScada on a single server.