Virtual machine gaming

How to make your gaming experience less reliant on Microsoft

There was always going to come a day when computers would become so fast that we could run multiple operating systems simultaneously, side by side. It was predicted about 35 years ago, in fact.

While this prediction did come true, it never came true in the way the analysts expected. They envisioned massive computers with their ‘CPU’ and ‘RAM’ physically caged off between separated concurrent operating systems. The truth was, the concept of the hypervisor would be born, and ‘to the metal’ instruction passing would become the accepted way to virtualise.

All this gave way to the VMware, Xen, Zones, Jails and Parallels we know today. Atomic folk are a pretty experienced lot concerning virtualisation, being treated to regular guides and in-depth tutorials on such concepts. We’ve been serious for too long.

Let’s have some fun.

Experiment responsibly
Both Parallels and VMWare Fusion now experimentally support Direct3D/OpenGL hardware acceleration within Windows XP as the client OS. This gives us free run of all those lovely shader pipelines and hardware transform/lighting streams. Creating an ideal environment for this schizophrenic gaming powerhouse is a fine art.

We’ll be using Parallels 3 build 4560/VMWare Fusion beta RC1 (on the Mac) and VMWare Workstation 6 (Windows/Linux) as our base. We’ll assume you have an existing installation of your virtualisation product on your MacBook Pro/iMac/Mac Pro or generic x86-based computer.

Disk preparation
Our primary testbed is Mac OS X, so we’ll explain disk layout here first. You’ll need to create a new partition, ideally, for such exploits as virtualised gaming. The reason behind this relates to segregated IO on your physical storage media. In a perfect world, you’ll have a new HFSX (note, this is not HFS+, but journalled, case-sensitive HFS) partition living on a totally separate physical volume from your system disk. We recommend an additional internal SATA drive or a separate, external FireWire-connected disk.

Similarly, if your virtual host is Windows/Linux-based, it is wise to have separate partitions and, in a best case scenario, totally separate physical disks to target for your virtual machines.



Creating a HFSX volume can be accomplished via the command line or the GUI in Mac OS X. It is always most simple to use the graphical Disk Utility.app tool found in /Applications/Utilities/Disk Utility.app.

The above image illustrates the drop-down capable box used for HFSX formatting, within Disk Utility.app.

If virtualising with a Windows or Linux host, it is expected that you’ll use a native format for your platform, such as NTFS for Windows XP/Vista and ext3 or ReiserFS for Linux. We strongly discourage the use of FAT32 for these purposes. If you have the technology at your fingertips, ZFS or SAM-QFS are ideal and will provide maximum performance, albeit at a significant cost and could be considered overkill.

Our gaming volume is a partition on a standalone physical disk around 40GB in size, connected via FireWire. We’ve made the partition this large so we can comfortably fit a virtualised operating system as well as several games/swap space and other applications onto the virtual client.

CPU considerations
Don’t do this without a dual-core environment. Just don’t. Virtualisation hypervisors love exploiting the use of SMP to the extent that they are allowed. Given that we’re attempting to render a whole graphics and audio subsystem while we have a primary OS running above it all, you start to come to grips with the wisdom in multiple cores. As a bare minimum a Core 2 Duo or AMD X2-series 64-bit CPU should suffice. Those with Mac Pro’s are in for a treat, with the raw power of dual Xeon Core 2 Duo-based processors feeding your virtual machines quite effortlessly.

Memory considerations
Fortify yourself with at least 2GB of RAM. We’ll be ducting 1GB to our virtual machines. Most games recommend upwards of this amount as a standard specification currently, so we will give our virtualised titles a fighting chance. If you are running a 32-bit host, your effective memory ceiling is 4GB. If you are running a 64-bit host and have the appropriate hardware, you can go well above this limit, but keep in mind that you may need to enable memory remapping flags within your system BIOS in order to escape memory-write holes/remap discrepancies above 4GB, which virtual machines tend to be fussy about.