NOTE: See additional information for VMWare at the end of this article.

Cyrious' answer is that you can, but you should not. Unless you have a very high-end (expensive) version of SQL Server, your performance may be dramatically worse . The reason you should not run SQL on a virtual machine is not really technical - it is a combination of the way processors are handled in virtual machines and the licensing that applies to every version of SQL Server. See Microsoft's article on this subject.

Each version of SQL Server (except the Enterprise version) is restricted so it will only run on a certain number of processors. Microsoft SQL Server Express, the default for new and smaller users, is restricted to 1 physical processor (a single chip) and up to 4 cores. Most modern processors have several cores, and a server computer would typically have at least 4 cores. A core can be thought of as a separate processor that works closely with others in the same chip. Each core can also enable hyper-threading, which splits its power among two different “virtual processors”.

A quad-core processor with hyper-threading enabled has 8 virtual processors on a single chip, all of which SQL Server Express can use because SQL Express supports 1 physical processor, 4 cores. For businesses with only a few users, this is normally plenty of processing power.

However, with a virtual machine (VM) something different happens. In a VM, all of the underlying hardware is removed from direct view. What the VM sees and can access are all controlled by what the physical machine (PM) and VM Server technology reveals. The VM has no direct access to the hardware. In practice, some direct access is used for coordination. But in practice, the VM should not know the details of the PMs hardware.

In this case, each virtual processor on the PM is “presented” to the VM as if it were a real processor. This doesn't change the processing power, so it normally doesn't affect performance. However, because of the licensing restrictions for Microsoft SQL Server, this results in a dramatic reduction in the real processing power SQL will use. In practice, it may result in a reduction between 1/4th and 1/16th of processing power available to SQL.

Such a reduction in processors available to SQL can result in dramatic slowdowns and problems. For this reason, unless you are running the Enterprise version of SQL (which may cost you tens of thousands of dollars), Cyrious strongly recommends you not put SQL Server on a virtual machine.

The example above showed the reduction for SQL Express, but a similar problem exists for all versions of SQL Server except Enterprise.

The processor limits for other versions of SQL Server 2017 are:

There is no inherent problem with running Control on a virtual machine, however, the added layer of the virtual machine will always result in a slight performance loss when compared with a physical machine. Running and maintaining a virtual machine environment requires trained IT skills. There is an added layer of complexity and performance tuning/maintenance that is required to effectively deploy a Virtual Machine environment. Cyrious does not recommend this configuration for any customer without a trained and certified staff (internal or external).

With VMWare ESX 5.x the default is 1-core per CPU, you can alter the number of cores given to a CPU. This will overcome many of the problems described here by allowing SQL Express to use the extra processing capabilities normally found in a CPU. For more information, see VMWare's Documentation.

Note: Configuring a VMWare server is not something the Cyrious technicians are trained or permitted to do. Your network administrator will need to perform this function her/himself.

• Entered: 01/2010
• Updated: 06/2019
• Version(s) : All versions of Control.