In a previous issue of The NT Insider (Volume 9 Issue 1), we reviewed the VMWare product.  Unfortunately, we weren’t able to use it for running Windows XP® sessions, but they have now released an updated version (3.1) that appears to resolve the problems that we were experiencing here at OSR.

In addition, several other people pointed to a different virtual machine product by Connectix (http://www.connectix.com) that appears to come from the Macintosh environment originally and now runs on the Windows platform as well (See Figure 1).

Figure 1 — Connectix Virtual PC

Both products serve similar purposes, although there are certainly some differences between the two of them.  No doubt each product will have its proponents. Our goal (of course) is to find new and interesting ways to facilitate our own kernel development.

One of the tantalizing draws to using VMWare or Connectix is the ability to simulate a multi-machine environment without actually having multiple machines. Further, because they each allow you to optionally make changes “undoable” you can run the virtual machine and then decide to throw away all the changes made during that running session! There’s certainly a market in this for people who build and maintain servers (server infected? Oh, well, just reboot and throw away the changes.) Making backups is also pretty simple, as the “disk drives” for these machines are nothing more than files on the local native Windows file system. So you make a backup by copying the hard drive image files.

For example, suppose you need to have your very own domain of Windows servers (for whatever reason your product needs ) but you don’t want to tie up three or four physical machines in that process. If you have one well-equipped machine (and here memory seems to be the #1 key to success) you can create several virtual machines (each with their own memory allocation, so let’s say 256MB each). Your machine needs to have about twice as much memory as you have allocated to all of your virtual machines combined – so if you are simulating four 256MB machines, you should figure on adding 2GB of physical memory! For both products, these machines can be isolated so they can “see” one another, but cannot see the rest of the world. Alternatively they can be bridged in which case, each one of these machines has its own Ethernet address and IP address and thus look like real computers to the outside world (if this is important). We’ve used it internally to allow us to have one machine running, connected to a remote VPN, without losing total connectivity for everything else we were doing on the machine.

Of course, for a kernel developer, Nirvana would be to allow kernel debugging from one machine to another, or between the host machine and the guest machine. We were able to successfully do this with VMWare, but could not do this with Connectix (they tell us it will be available “in a future release”). The VMWare solution relies upon a pipe mechanism and this can then be used with WinDBG to debug on the same machine (See Figure 2). There are a few “tricks” to setting this up:

Figure 2 — Connectix Use of Pipes for Debugging

On the VMWare machine, you must connect a serial port to a named pipe

The VMWare configuration must enable “Yield CPU on poll”

You must start the VMWare machine before starting the debugger

Start the debugger with the command line option –k “com:port=\\.\pipe\<pipe name,pipe”

Having done this, you then end up with a debuggable machine. From this point, you can proceed to enable serial debugging as if this were a normal debug system. Thus, you must still make the changes to the boot.ini file, etc. Once the debugger and debugee are hooked up, you can proceed to debug as normal (See Figure 3).

Figure 3 — VMWareWorks with WinDbg!

There are still limitations to the products – serial debugging is not much faster via a pipe than it is over a real serial cable (ah, for the virtual 1394 connection!) These virtual machines only simulate uni-processor environments. They are slower than real computers. Debugging a virtual machine only works if you don’t have hardware you need to install into the machine.

One particular annoyance that arises when working with Windows XP (and presumably .NET as well) is the activation feature (See Figure 4). While the license agreement for Windows XP suggests that it would apply (since it is bound to the physical computer) the activation logic is not nearly so clever - it thinks of this new machine as a separate physical computer and thus it requires a separate activation. This is fine if you are fortunate enough to have an activation key with plenty of activations available, but if you are stuck with a standard two-activation key, be prepared to spend lots of time on the telephone with Microsoft to obtain additional authorizations.

Figure 4 — "Friendly" Activation Feature

Still, it is quite nice to be able to build and debug on a (generously configured) laptop system. It isn’t going to replace our standard development environment, but it will help augment it.

Overall, our evaluation this time around is positive – these two products are worthy of your consideration.

For additional information on these products, please refer to their respective web sites, http://www.vmware.com and http://www.connectix.com.