Playing "let's pretend" is always a highlight for kids. It lets them be people and have things that aren't possible in the real world. A kitchen chair and a skipping rope can magically become a noble steed, and a toilet plunger makes a great blunderbuss.

Developers can play "let's pretend" too, when it comes to testing or evaluating software. Instead of risking their primary system by loading programs of, shall we say, dubious quality and stability, they can load them up on virtual machines.

Like the kitchen chair horse, unpleasant consequences of the real thing (such as piles of steaming manure on Mom's best carpet, or a completely gorched operating system) only happen in that let's-pretend world; the real carpet and the real system are isolated from bad things. But unlike the childhood fantasy, a developer working on a virtual computer can do some serious, real testing.

In case you're not acquainted with the technology, virtual computers are logical instances of everything that makes a computer — CPU, storage, NIC, operating system, and so forth — that live on a host machine that may be running a completely different OS. A virtual machine (VM) is usually encapsulated in a file on the host, so you can, in effect, copy a whole "computer," complete with hardware, software and configuration, from host to host.

For software developers, VMs can replace or alleviate the need for a collection of computers for building and testing new applications. Do you want to test Linux apps, but only have a Windows machine available? Create a virtual machine on it and test away; Microsoft has even announced support for Linux VMs on Windows hosts running its VM solutions. Do you need several versions of Windows available for compatibility testing of your apps? Don't multi-boot, just build VMs and fire them up as needed (but remember, a virtual system needs a real operating system license!). You can even go back to the future with a DOS VM!

What else is a VM good for? How about for migrating a mission-critical Windows NT 4.0 system off geriatric, dying hardware onto a VM on a shiny new box. Or building a (virtual) server farm on a single robust machine, keeping hardware, power and cooling costs under control while still providing independent "machines" for applications that need to be isolated. And if you need a network to demo your new app, create a virtual one on your laptop.

You will discover, naturally, the price for this convenience. Aside from any cost for the software that creates and runs VMs, there is some overhead on the host machine. You may need to kick up the RAM or add disk space, and you'll definitely have to have legal copies of the OSes you want to run on the VMs (the "guest" OSes). On the plus side, virtual machines take up virtual floor space, and don't need extra power or cooling. And it's easier to clean up virtual messes if a test application goes kaboom.

Some vendors are distributing evaluation versions of their software on optimized VMs, so prospects see the products at their best without spending hours on setup (and possibly messing up the system used for the eval in the process). VMWare, a long time provider of VM software, has released a free VMWare Player that runs any virtual machine created by VMware Workstation, GSX Server, or ESX Server. VMware Player also supports Microsoft virtual machines and Symantec LiveState Recovery disk formats. It also has a free player for virtual servers. Microsoft has recently taken the further step of releasing its entire Virtual Server 2005 product as a free download; you still pay for Virtual PC 2004.

The open source community hasn't been sitting on its hands, either. Xen is an open source para-virtualization product that approaches virtualization from a slightly different angle. To get the best performance, the operating systems you want to run on Xen's virtual machines must be customized for it; you can't just toss your OS CD onto the drive and install an instance of it on a virtual machine as you can with the VMWare or Microsoft products. Xen acts as the host, inserting a software layer between the hardware and the operating system. This approach can limit your options (many OS vendors don't want people messing with their systems), but it also cuts Xen's overhead to around five percent. Application software will run unaltered on Xen VMs.