They say two heads are better than one, and virtualization is no different. The more CPUs you have available in a computer that runs virtualized machines, the more processing power you can share among the virtual computers. But the presence of multi-core CPUs complicates the picture a little bit. Can a computer with four physical processors support the same virtualized load as a two-CPU system with two cores per CPU? And if so, does anything special need to be done anyway?
This issue is becoming more important now that almost every server-level computer shipped these days (even those with only one processor) includes processors with multiple cores or a hyper-threaded architecture that presents the system with multiple virtual processors. Processing power is like memory -- more is almost always better, but how it's used is equally important.
Here are some guidelines about using multi-core systems with virtualization:
1. Leave at least one physical processor free whenever possible.
If you have more than one physical processor and some degree of control over which processors are used by your virtualization system, leave at least one entire physical processor for the rest of the system.
Here's an example. If you have a four-way server (a server with four physical processors), you can assign Virtual Server to use three of them among its virtualized machines and keep the fourth for the rest of the system at large.
The reason why you want to keep a whole physical processor for the rest of the system, no matter how many cores are in that processor, is simple enough. The other tasks being processed by the rest of the server deserve a full physical processor to themselves so that they're not contending with virtualized machines running in other cores on the same socket. Keep in mind that even if Virtual Server is the main application for that server, it's not going to be the only thing of consequence running on that server by a long shot. Virtual Server relies on an instance of IIS, for instance, for its management interface.
2. Be mindful of the per-processor licensing requirements for your software, if any.
Some of the programs you'll run in multi-core or multi-processor virtualized environments might have specific licensing constraints. The good news is that many companies are scrambling to do something about it, and in the long run, it may benefit you.
Microsoft, as you can imagine, was one of the first. As of December 2005, the licensing for Microsoft server products was recast on a per-product-instance, rather than per-processor or per-processor-core basis. For instance, if you have four instances of SQL Server running on four different virtualized machines, you'll need to pay licensing costs for each separate instance of SQL Server even if they are all running on the same physical machine.
On the other hand, if you have a single 32-processor server with one instance of SQL Server installed throughout, you pay for only one license. If you have multiple virtualized machines that use databases, for instance, it might make more sense to consolidate all the databases into a single shared instance or another physical server rather than running multiple instances on each virtual machine and paying multiple and possibly redundant licensing costs.
3. If your virtualization software has CPU allocation settings, use them.
Most virtualization software including Microsoft Virtual Server has settings that control how CPU usage is allocated across virtual machines. Virtual Server assigns a relative value to each machine; machines with a higher value can use more CPU. This works equally well across multiple processor cores, as well as multiple physical processors.
4. Multi-threaded processing may be a bad idea under very heavy loads.
If the virtual servers you're running are going to experience heavy loads (75% processor utilization or better), and you're running on a server that supports hyper-threading, turn hyper-threading off. On heavily loaded systems, hyper-threading hurts performance of virtual machines and should not be used.
Serdar Yegulalp wrote for Windows Magazine from 1994 through 2001, covering a wide range of technology topics. He now plies his expertise in Windows NT, Windows 2000 and Windows XP as publisher of The Windows 2000 Power Users Newsletter and writes technology columns for TechTarget.
This was first published in August 2006